-
Notifications
You must be signed in to change notification settings - Fork 13
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
System DLLs are hardcoded to the C: drive #9
Comments
The linker comments are resolved at compile time, so using a macro or environment variable will only make it work for the setup that you have on the machine which it was built on. I do have solutions for this issue coming up at some point though. |
hi I would love to fix this! I think you could do something like:
This should allow you to build all references dinput8.dll dynamically, agnostic to the system drive path. I'd love to add this in and make a pull request if you give me permissions. |
This does work, however this makes it so the forward exporting/proxying is done at runtime and could theoretically cause race conditions, unless combined with a waiting/spinlock mechanism when the proxy functions are called before the proxy is ready (which I have tried and then experienced issues in some cases, namely with late calls to GetProcAddress when third party hooks are involved). That's why the exports are done the way they are now, statically declared at compile time, so there are no race conditions or other issues - except for the hardcoding to the C drive. However I have made a library which deals with DLL proxying without all the ugliness and problems, which I will add to EML at some point, I just haven't been programming for a while. https://github.com/techiew/UniversalProxyDLL |
Could the following work at all? I believe the env variable "SYSTEMDRIVE", this should return where ever the windows folder is located, example:
I don't know if this gets around any of the conditions you mentioned that were causing issue~ It would be rather strange for someone to install on non C:\ drive letter..... |
I'm unfamiliar with Visual Studio; does it still work if you replace
C:\\\\Windows
with%SYSTEMROOT%
? This is the usual way to get the location of the Windows folder regardless of which drive it's on.The text was updated successfully, but these errors were encountered: