Closed EssenOH closed 1 year ago
Due to the DLL search order, the executable should first search for required DLLs in the executable directory before checking system folders and so on. Is dinput8 actually a DLL that is imported by the game in this case?
Actually, that is my question point as well and then how can I make sure the DirectX App. utilized the new generated dinput8.dll file within the same directory ? I assumed that the DirectX App. internally scans the dinput8.dll within the same directory 1st...otherwise, the DLL search order should be defined somewhare...
I just used simple DirectX sample application from "DirectX-Graphics-Samples/Samples/Desktop/D3D12HelloWorld/src /HelloTriangle/"
I doubt the sample application you're linking to is importing dinput8. Here's how to check imported DLLs of an exe: https://stackoverflow.com/questions/475148/how-do-i-find-out-which-dlls-an-executable-will-load
If dinput8 is not being loaded you will need to create a different proxy DLL. On that note I am in the process of creating a DLL proxying library which would for example allow this DirectXHook project to be renamed at any time to any other DLL and forward export correctly, without any modification.
For now, check this one out for example: https://github.com/maluramichael/dll-proxy-generator
I also realized that the the sample application may not be possible scanning the dinput8.dll in the same directory because the "mod" games already has the proxy functionality, but the general DX application doesn't have it. Thanks for quick response and the shared information. let me take a look.
I expected that the APIs in /Windows/System32/dinput8.dll should be called for the general DX Apps, but utilizing the "dumpbin" application, the DX sample application does't call anything.
so, I am wondering if I replace the /Windows/System32/dinput8.dll with the new one, does it affect to the application ?
My assumption was that it should work with a little modification of the source code to load "dinput8_original.dll" after replacing original with new one if the DX App. absolutely call the APIs in dinput8.dll and the mechanism is exactly same as the DLL Proxy implementation.
If the application does not utilize any exported functions of dinput8, then dinput8 will not show up when you use dumpbin and the application will not attempt to load the DLL whatsoever. Doesn't matter if the DLL is in system32 or in the current directory. I do not recommend messing with any DLLs in your system32 folder!
I'm actually not sure what's the best way to tell your executable which DLLs to load, but if you either call a function provided by the DLL or specify somewhere in Visual Studio that you require dinput8, then the application will load it and your dinput8 proxy code will be called. However I would recommend simply creating a different DLL proxy like I mentioned above. I'm not sure which DLLs your test application is loading, but I would assume it is at least loading dxgi.dll, so try to set up a proxy for that one.
In order to make simpler verification of the solution, I removed the directories except "Example" sub directory. After that, I slightly retouched the source file to remove the header file inclusions from the removed directories. I also retouched the VC project file for the "post event" to copy the font file & texture file and dinput8.dll within the executable directX application directory. so, I expected that invoking the directX application with clicking the executable file is going to automatically scan the dinput8.dll within the same directory and launch it, but nothing is happening.