Windows: Fix EnumDevices stall using IAT hooks.

[bruvzg]

Fixes #20566
Fixes #105271
Fixes #110663

Same as #76810, but without DLL files.

I do not like this, but since it seems to be still relevant even after switching to SDL and no better solution was found, it should be OK.

Note: I do not have any device that triggering the issue, so only tested that it's intercepting the same methods as #76810

[Raicuparta]

I've tested the same empty project with this build and with a stable 4.5 build.
With the sable build there's a clear multiple second delay when some of my USB devices are connected.
With this build there's no discernible difference in time until playable.
Seems fully fixed.

[akien-mga]

Looks good to me.
Let's get this tested in the next dev snapshot and get wider confirmations that it solves the problem (or not).

[Repiteo]

Thanks!

[Ranoller]

Thanks! This was a major bug in Godot. Please consider cherrypick to Godot 3 branch.

[akien-mga]

I'm running into this compilation error on Fedora 40 with MinGW 11.0.1 and GCC 14.1.1.
Not reproducible on Fedora 43 with MinGW 13.0.0 and GCC 15.2.1.

$ scons p=windows d3d12=yes dev_build=yes scu_build=yes fast_unsafe=yes
...
/usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: bin/obj/platform/windows/os_windows.windows.editor.dev.x86_64.o: in function `_hid_is_controller(void*)':
/root/godot/platform/windows/os_windows.cpp:2765:(.text+0xe837): undefined reference to `HidD_GetPreparsedData(void*, _HIDP_PREPARSED_DATA**)'
/usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: /root/godot/platform/windows/os_windows.cpp:2771:(.text+0xe86b): undefined reference to `HidP_GetCaps(_HIDP_PREPARSED_DATA*, _HIDP_CAPS*)'
/usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: /root/godot/platform/windows/os_windows.cpp:2772:(.text+0xe87a): undefined reference to `HidD_FreePreparsedData(_HIDP_PREPARSED_DATA*)'
/usr/lib/gcc/x86_64-w64-mingw32/14.1.1/../../../../x86_64-w64-mingw32/bin/ld: bin/obj/platform/windows/os_windows.windows.editor.dev.x86_64.o: in function `Hook_HidD_GetProductString(void*, void*, unsigned long)':
/root/godot/platform/windows/os_windows.cpp:2793:(.text+0xe953): undefined reference to `HidD_GetProductString(void*, void*, unsigned long)'
```-

[bruvzg]

I'm running into this compilation error on Fedora 40 with MinGW 11.0.1 and GCC 14.1.1:

Likely an issue with hid.lib import lib in older MinGW runtime version, I'll check it.

[akien-mga]

Cherry-picked for 4.5.2.

[BuzzLord]

I'm running into this compilation error on Fedora 40 with MinGW 11.0.1 and GCC 14.1.1.

I'm running into this issue on the latest Ubuntu LTS release 24.04.3, which ships with MinGW 11.0.1. It might be prudent to update the Compiling for Windows docs to mention which version of MinGW is required to build the engine.

[akien-mga]

No we should fix the build regression.

[bruvzg]

The only way to fix it on old MinGW is probably to load these function dynamically.

[akien-mga]

From a quick check the definitions do seem to exist in MinGW 11.0.x, so I'm not sure what changed in later versions.

~/tmp/mingw-w64 ((v11.0.0))$ rg --sort=path HidD_GetPreparsedData
mingw-w64-crt/lib-common/hid.def
21:HidD_GetPreparsedData

mingw-w64-crt/lib32/hid.def
15:HidD_GetPreparsedData@8

mingw-w64-headers/include/hidsdi.h
61:BOOLEAN NTAPI HidD_GetPreparsedData (HANDLE HidDeviceObject, PHIDP_PREPARSED_DATA *PreparsedData);
~/tmp/mingw-w64 ((v11.0.0))$ git checkout master 
Previous HEAD position was f9500e2d8 crt: Regenerate Makefile.in
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
~/tmp/mingw-w64 (master)$ rg --sort=path HidD_GetPreparsedData
mingw-w64-crt/lib-common/hid.def
21:HidD_GetPreparsedData

mingw-w64-crt/lib32/hid.def
15:HidD_GetPreparsedData@8

mingw-w64-headers/include/hidsdi.h
65:BOOLEAN NTAPI HidD_GetPreparsedData (HANDLE HidDeviceObject, PHIDP_PREPARSED_DATA *PreparsedData);

[akien-mga]

Maybe https://sourceforge.net/p/mingw-w64/mingw-w64/ci/04ae98c97503f0bc56ff80a40978a8481dcdd7e7/ ?

Not sure what's the implication but could be worth checking if it builds fine if we move this code to .c files.

[bruvzg]

I guess we can try adding extern "C" {} around <hidsdi.h> include.

[akien-mga]

Yeah I'm testing this now.