Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using Win8 features requires allocation changes #63

Open
tormodvolden opened this issue Feb 11, 2024 · 5 comments
Open

Using Win8 features requires allocation changes #63

tormodvolden opened this issue Feb 11, 2024 · 5 comments

Comments

@tormodvolden
Copy link
Contributor

As soon as we start using USBD_CLIENT_CONTRACT_VERSION_602 in order to access USBD_HANDLE [1] and the new stuff in usbdex.lib, we also have to fulfill the "contract" [2], and use the Win8 USB allocation routines [3] etc.

[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/usbdlib/nf-usbdlib-usbd_createhandle
[2] https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-client-driver-contract-in-windows-8
[3] https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/how-to-add-xrb-support-for-client-drivers

@mcuee
Copy link
Owner

mcuee commented Feb 11, 2024

Interesting. Last time Travis and I did test libusb0.sys and libusbK.sys (along with WinUSB) under Windows 10/11, using libusbK.dll.

@tormodvolden
Copy link
Contributor Author

We only started using the "contract" features in commit 65f9a19, two days ago. And it is not like you will necessarily see any problem, Windows will just not guarantee anything and there might be "bug checks".

@dontech
Copy link
Collaborator

dontech commented Feb 12, 2024

Tormod, again you are spot on. Super annoying :-) 👍

However, unless the driver verifyer starts complaining, I am going to try to push these changes until we deprecate Windows 7 support.

For now, it would seem it still works fine to use the old APIs. I guess MS probably made it backward compatible even though the docs suggest that it is not recommended.

All my testing shows that it seems to work.

But thanks again for staying on top of this.

@dontech
Copy link
Collaborator

dontech commented Feb 12, 2024

Additionally it is worth noticing that this is not a win8 feature, but actually is supported all the way back to Vista.
It was introduced in the win8 SDK, but was O/S backported to win7/vista.
So the binary interface is only missing in older versions of those O/S

The docs state:

Requires WDK for Windows 8. Targets Windows Vista and later versions of the Windows operating system.

@tormodvolden
Copy link
Contributor Author

tormodvolden commented Feb 12, 2024

Right. When linking in the usbdex.lib, these features will work on Vista/Win7 as well. So when I was saying "build for pre-win8" I should rather have said "build with pre-win8 SDK". Which for now unfortunately affects MinGW. If usbdex was a run-time library like usbd.sys, we could have worked this out for MinGW quite easily. But with the statically linked usbdex.lib it gets more hairy: MinGW doesn't ship any equivalent functions or library. And if linking in an usbdex.lib (I tried, I found one on a machine even without having the SDK on it [1]), it has a lot of new dependencies:

$ x86_64-w64-mingw32-gcc -o libusb0.sys abort_endpoint.o claim_interface.o clear_feature.o dispatch.o get_configuration.o get_descriptor.o get_interface.o get_status.o ioctl.o libusb_driver.o pnp.o release_interface.o reset_device.o reset_endpoint.o set_configuration.o set_descriptor.o set_feature.o set_interface.o transfer.o vendor_request.o power.o driver_registry.o error.o libusb_driver_rc.o  libusb0_drv.def -s -shared -Wl,--entry,DriverEntry -nostartfiles -nostdlib -L. -lusbd -l:usbdex.lib -lntoskrnl -lhal
/usr/bin/x86_64-w64-mingw32-ld: libusb_driver.o:libusb_driver.:(.text+0xd97): undefined reference to `__imp_USBD_CreateHandle'
/usr/bin/x86_64-w64-mingw32-ld: libusb_driver.o:libusb_driver.:(.text+0xdc0): undefined reference to `__imp_USBD_QueryUsbCapability'
/usr/bin/x86_64-w64-mingw32-ld: pnp.o:pnp.c:(.text+0x31b): undefined reference to `__imp_USBD_CloseHandle'
/usr/bin/x86_64-w64-mingw32-ld: ./usbdex.lib(d:/os/obj/amd64fre/minkernel/usb/usbdex/objfre/amd64/usbdex.obj):(.text$mn+0xa): undefined reference to `__security_cookie'
/usr/bin/x86_64-w64-mingw32-ld: ./usbdex.lib(d:/os/obj/amd64fre/minkernel/usb/usbdex/objfre/amd64/usbdex.obj):(.text$mn+0x85): undefined reference to `__security_check_cookie'
/usr/bin/x86_64-w64-mingw32-ld: ./usbdex.lib(d:/os/obj/amd64fre/minkernel/usb/usbdex/objfre/amd64/usbdex.obj):(.text$mn+0x108): undefined reference to `RtlStringCbCatW'
/usr/bin/x86_64-w64-mingw32-ld: ./usbdex.lib(d:/os/obj/amd64fre/minkernel/usb/usbdex/objfre/amd64/usbdex.obj):(.text$mn+0x1f): undefined reference to `__security_cookie'
/usr/bin/x86_64-w64-mingw32-ld: ./usbdex.lib(d:/os/obj/amd64fre/minkernel/usb/usbdex/objfre/amd64/usbdex.obj):(.text$mn+0x374): undefined reference to `__security_check_cookie'
/usr/bin/x86_64-w64-mingw32-ld: ./usbdex.lib(d:/os/obj/amd64fre/minkernel/usb/usbdex/objfre/amd64/usbdex.obj):(.text$mn+0x13): undefined reference to `__security_cookie'
/usr/bin/x86_64-w64-mingw32-ld: ./usbdex.lib(d:/os/obj/amd64fre/minkernel/usb/usbdex/objfre/amd64/usbdex.obj):(.text$mn+0x26a): undefined reference to `__security_check_cookie'
/usr/bin/x86_64-w64-mingw32-ld: ./usbdex.lib(d:/os/obj/amd64fre/minkernel/usb/usbdex/objfre/amd64/usbdex.obj):(.xdata[$unwind$USBD_QueryUsbCapability]+0x18): undefined reference to `__GSHandlerCheck'
/usr/bin/x86_64-w64-mingw32-ld: ./usbdex.lib(d:/os/obj/amd64fre/minkernel/usb/usbdex/objfre/amd64/usbdex.obj):(.xdata[$unwind$USBD_CreateHandle]+0x1c): undefined reference to `__GSHandlerCheck'
/usr/bin/x86_64-w64-mingw32-ld: ./usbdex.lib(d:/os/obj/amd64fre/minkernel/usb/usbdex/objfre/amd64/usbdex.obj):(.xdata[$unwind$InitializeNonPagedPoolType]+0xc): undefined reference to `__GSHandlerCheck'
collect2: error: ld returned 1 exit status

The __imp_USBD* names I think can be sorted out (maybe I made an error) but the __security_cookie and __GSHandlerCheck point to further libraries that need to be added. If they are not so many, I would still be interested in getting it to work, but it is a pity that it just won't build with MinGW out of the box any longer, and bits and pieces (probably with restrictions on redistribution) needs to be added.

[1] from C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22621.0\km\x64

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants