Skip to content
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

Open
ketsuban opened this issue Apr 5, 2023 · 4 comments
Open

System DLLs are hardcoded to the C: drive #9

ketsuban opened this issue Apr 5, 2023 · 4 comments
Assignees

Comments

@ketsuban
Copy link

ketsuban commented Apr 5, 2023

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.

@techiew
Copy link
Owner

techiew commented Apr 5, 2023

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.

@rmilejcz
Copy link

hi I would love to fix this! I think you could do something like:

#include <Windows.h>

int main() {
    char buffer[MAX_PATH];
    UINT length = GetSystemDirectoryA(buffer, MAX_PATH);
    if (length > 0 && length < MAX_PATH) {
        // The path is stored in the 'buffer' variable
        printf("System directory: %s\n", buffer);
    } else {
        printf("Error retrieving system directory.\n");
    }
    return 0;
}

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.

@techiew
Copy link
Owner

techiew commented May 22, 2024

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

@pceimpulsive
Copy link

Could the following work at all?

I believe the env variable "SYSTEMDRIVE", this should return where ever the windows folder is located, example:

PS C:\Users\pceim> $env:SYSTEMDRIVE
C:
#include <stdlib.h>

// Function to retrieve the value of an environment variable
int getEnvVar(const char* name, char* buffer) {
    return GetEnvironmentVariable(name, buffer, MAX_PATH);
}

// Example usage in your DLL
char envVar[MAX_PATH];
getEnvVar("SYSTEMDRIVE", envVar);

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.....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants