The mod loader currently uses linker comments to forward export functions to dinput8.dll.
Linker comments are used instead of setting up the forward exports at runtime inside the mod loader thread (with LoadLibrary and GetProcAddress) because the runtime exporting introduces a race condition where dinput functions may be called before the forward exporting has finished setting up. Using linker comments sets up the forward exports at compile time and thus avoids this issue.
However this solution will not work if Windows is not installed on the C drive, although this should not be a problem for the majority of users.
In practice I don't think runtime forward exporting should be a problem, as I've observed that the first function call to dinput seems to happen about 5-10 seconds after the game has started, which should in theory give us plenty of time to set up the forward exports. But I've chosen the solution with known consequences instead of the solution with undefined consequences.
As an attempted solution, I tried making it so the exported functions forward exported themselves when they were called at runtime, this would be the best of both worlds as there would be no race condition and you could code it so it dynamically retrieved the system directory containing dinput8.dll. However I faced an issue with GetProcAddress returning the address of a function contained in a EOS (Epic Online Services) DLL instead of dinput8.dll, which I was unable to solve. I don't know why this happens, only that it happens if GetProcAddress is called after the game has been open for some seconds.
The mod loader currently uses linker comments to forward export functions to dinput8.dll.
Linker comments are used instead of setting up the forward exports at runtime inside the mod loader thread (with LoadLibrary and GetProcAddress) because the runtime exporting introduces a race condition where dinput functions may be called before the forward exporting has finished setting up. Using linker comments sets up the forward exports at compile time and thus avoids this issue.
However this solution will not work if Windows is not installed on the C drive, although this should not be a problem for the majority of users.
In practice I don't think runtime forward exporting should be a problem, as I've observed that the first function call to dinput seems to happen about 5-10 seconds after the game has started, which should in theory give us plenty of time to set up the forward exports. But I've chosen the solution with known consequences instead of the solution with undefined consequences.
As an attempted solution, I tried making it so the exported functions forward exported themselves when they were called at runtime, this would be the best of both worlds as there would be no race condition and you could code it so it dynamically retrieved the system directory containing dinput8.dll. However I faced an issue with GetProcAddress returning the address of a function contained in a EOS (Epic Online Services) DLL instead of dinput8.dll, which I was unable to solve. I don't know why this happens, only that it happens if GetProcAddress is called after the game has been open for some seconds.