• Advertisement
Sign in to follow this  

Win32 API: Working Dir

This topic is 4317 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi, I didn't find it: What Win32 functions returns the working dir of a process (like getcwd)? bye Chris

Share this post


Link to post
Share on other sites
Advertisement
Thanks!

GetCurrentDirectory is useful. But it would be really interesting if you can get it for any process.

Share this post


Link to post
Share on other sites
I suspect that the only way to get another processes working directory would be to inject a DLL into the process and call GetCurrentDirectory from there.

Why would you need to know another processes working directory anyway?

Share this post


Link to post
Share on other sites
Here's the problem:

I'm writing a DLL which gets loaded in an isapi filter (I don't have the source). Now I load a DLL myself. But it can only be found if it is located at "C:\WINDOWS\system32" (because the working dir of my dll is "C:\WINDOWS\system32" I guess) which I don't want. I want to put the DLL in the same directory as the isapi filter.
I thought I could get the working dir of the parent process to solve the problem...

Any ideas?

Share this post


Link to post
Share on other sites
I'm not sure, but I perhaps you could use EnumProcessModules to find the modules for a process and use GetModuleFileName (or GetModuleFileNameEx) to find their full path.
If that is what you're after.

Share this post


Link to post
Share on other sites
A DLL doesn't have a working directory, since it's not a process. If a DLL is loaded into a process, then it gets the parent processes working directory.
Is it not an option to let the user install it into the correct directory? If not, does the isapi filter have any registry entires saying where it's installed?

Using EnumProcessModules might work, but if the application changes it's working directory, that won't work properly.

How is this all working? Do you have an installer to install your DLL or something? You can't just run a DLL (Well, aside from the rundll command)...

Share this post


Link to post
Share on other sites
Quote:
Original post by Zoomby
But it can only be found if it is located at "C:\WINDOWS\system32" (because the working dir of my dll is "C:\WINDOWS\system32" I guess) which I don't want.

This is probably because Windows will always look for libraries in the system folders, or indeed in the same folder as the application is running.

Share this post


Link to post
Share on other sites
Quote:
You can't just run a DLL (Well, aside from the rundll command)?

You can load a DLL with the LoadLibrary Function. Did you mean that?

Share this post


Link to post
Share on other sites
Quote:
Original post by Zoomby
You can't just run a DLL (Well, aside from the rundll command)?
You can load a DLL with the LoadLibrary Function. Did you mean that?
That's loading it into a process. So you have a program to install the dll then?

I was just wondering if you have an installer program, or if oyu'd just be providing the DLL to the user. But then if you're looking at getting the current working directory, you obviously have a process.

Never mind, I'm gibbering [smile]

Share this post


Link to post
Share on other sites
Quote:
Original post by Zoomby
Here's the problem:

I'm writing a DLL which gets loaded in an isapi filter (I don't have the source). Now I load a DLL myself. But it can only be found if it is located at "C:\WINDOWS\system32" (because the working dir of my dll is "C:\WINDOWS\system32" I guess) which I don't want. I want to put the DLL in the same directory as the isapi filter.
I thought I could get the working dir of the parent process to solve the problem...

Any ideas?


Do you have a DllMain in your DLL? If so, record your module handle in the PROCESS_ATTACH event of DllMain. Then when the time comes, use:


HANDLE g_hModule; // Assuming you filled this in during DllMain

HANDLE LoadOtherDll(LPCTSTR pszDllName)
{
TCHAR szModule[MAX_PATH];
TCHAR szPathName[MAX_PATH];
LPTSTR pszFilename;

// Get our DLL's name (i.e. "c:\mydll\mydllname.dll")
GetModuleFileName(g_hModule, szModule, MAX_PATH);

// Doing this to get pszFilename, which will be "mydllname.dll"
GetFullPathName(szModule, MAX_PATH, szPathName, &pszFilename);

// Overwrite pszFilename with the supplied DLL name
wsprintf(pszFilename, pszDllName);

// Load the library, using our own path as the source path
return LoadLibrary(szPathName);
}

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement