Handle ordinals in GetProcAddress detour

[Kriper1111]

As it turns out, symbols exported by a DLL don't necessary have to have text symbols - but they do have a number, the symbol ordinal, which is a valid way to address and access the symbol. GetProcAddress supports this behaviour - in this case, the ordinal is passed as the pointer value. Which, in Doorstop's detour, still gets treated as a string, and which subsequently causes lstrcmp to segfault under some very specific conditions (i.e. when the calling module tries to resolve a procedure by its ordinal).

In my case Unity 6 was accessing the 0x65 ordinal of d3d12.dll (located in system directory). (Did some poking - the symbol is named, which is weird, and named "D3D12CreateDevice", which checks out.)

As per GetProcAddress docs, if the value of the lpProcName pointer is an ordinal, high-word value of the pointer must be zero. This pull request addresses that quirk by inserting HIWORD macro as an additional condition to the detour check routine.

On a side note, this trend of looking up function names by their ordinals may hinder the detour.. Although doubt using ordinals is that stable. Weird.

GetProcAddress docs: https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getprocaddress

[ishitatsuyuki]

fyi, usage of ordinals is generally rare (d3d12 is an exception here), but if you wish to intercept ordinal lookups as well, you can find out a list of matching ordinals (required for ABI) from Wine's source. Example: https://github.com/wine-mirror/wine/blob/78a4aa0f9b658cd7466c33bf3059d8e6f2d499c8/dlls/d3d12/d3d12.spec#L1-L3