Why doesn't Windows require a full file path when calling LoadLibrary, or for CLSIDs w/ registered DLLs, etc. In what situation would someone benefit from having to fall back on the DLL Search Order to find a dll?
I mean, variables such as %SystemRoot% or %ProgramFiles% could get you to the appropriate folder, and .\ would leave you in your current directory.. So why allow the vagueness?
For explicit linking with GetProcAddress() I would argue that one should use the absolute path to the DLL if at all possible.
For implicit linking with .lib files then the name of the DLL has to be determined at link time which rules out absolute paths.
It is safest to put the DLL in the same directory as the executable, under %Program Files% and protected by UAC, and to use the new DLL search order.
Related
What happens when an executable tries to access a .DLL that isn't loaded ?
Does it try to find it at system32 folder and load it or something else?
Also can someone please explain to me where in the ram .DLL are saved and referenced, I tried researching online but didn't find many good answers...
Thanks in advance
The best description for the search processed used that I've been able to find is in the documentation for LoadLibrary at MSDN. An excerpt from the Remarks section of that documentation:
When no path is specified, the function searches for loaded modules whose base name matches the base name of the module to be loaded. If the name matches, the load succeeds. Otherwise, the function searches for the file.
The first directory searched is the directory containing the image file used to create the calling process (for more information, see the CreateProcess function). Doing this allows private dynamic-link library (DLL) files associated with a process to be found without adding the process's installed directory to the PATH environment variable. If a relative path is specified, the entire relative path is appended to every token in the DLL search path list. To load a module from a relative path without searching any other path, use GetFullPathName to get a nonrelative path and call LoadLibrary with the nonrelative path. For more information on the DLL search order, see Dynamic-Link Library Search Order.
The search path can be altered using the SetDllDirectory function. This solution is recommended instead of using SetCurrentDirectory or hard-coding the full path to the DLL.
If a path is specified and there is a redirection file for the application, the function searches for the module in the application's directory. If the module exists in the application's directory, LoadLibrary ignores the specified path and loads the module from the application's directory. If the module does not exist in the application's directory, LoadLibrary loads the module from the specified directory. For more information, see Dynamic Link Library Redirection.
If you call LoadLibrary with the name of an assembly without a path specification and the assembly is listed in the system compatible manifest, the call is automatically redirected to the side-by-side assembly.
My code is using a library which is a static/implicitly linked DLL (let's call it DLLB) but on runtime it can't find it.
This is despite locating DLLB in the same directory as the code that calls it. (The calling code is itself a DLL, DLLA which is called from python, which is called from arcpy. I'm not quite sure why the python finds DLLA fine but DLLA doesn't find DLLB, despite them being in the same directory).
If I put the library DLL somewhere on the system path, everything works just fine.
But what's the best approach for deployment? Add an entry to the system path on the client machine, at install time? Modify the system path at runtime, from python, before loading the DLL? Something else?
Python must be specifying the full path to the DLL in the LoadLibrary call. This is recommended practice. If you specify only a module name, there is a risk of loading the wrong DLL, possibly introducing a binary planting vulnerability.
Note that although the default search path includes the directory the executable was loaded from, it does not include the directory other DLLs were loaded from. So the behaviour you're seeing is as expected.
If you can use dynamic loading, you can look up the path to DLLA and use it to construct the path to DLLB.
To get a module handle for DLLA, call GetModuleHandleEx. To get the full path to DLLA from the module handle, call GetModuleFileName. Check that the last element is DLLA.dll and replace it with DLLB.dll. You can then call LoadLibrary.
I want to make a dll with an exposed C function accessible to applications on the system.
Is there a better way to make it available than modifying %PATH%?
Because people don't like adding it to %PATH% here.
You have three options if you want to allow implicit linking to the dll :-
Create a native Win32 assembly that contains the dll and install it to WinSxS. This requires creating a simple .manifest file, the use of some crypto tools to sign the assembly (being the manifest file and the dll), and creating an MSI installer - or call IAssemblyCache directly to perform the actual install.
Install the dll to System32 - with this option you need to ensure the dll has a relativly unique name.
Ad the path to the dll to the someplace on the PATH (or modify path to point to the dll).
Other options if implicit linking to the C Function isn't critical:-
Create an COM interface that exposes the c-method. Register the path to the dll in the registry and users of the dll use CoCreateInstance to get the interface containing the function.
Store the path to the dll in the registry, and expect users of the dll to use that path with LoadLibrary, and GetProcAddress to load the dll.
Put it somewhere in your PATH. (C:\Windows\System32\ comes to mind). If it's only needed by one application, just stick it in the same directory.
If you call the DLL using an import library, then it looks in the current directory, and then in the PATH.
But, you don't need to call it that way. You can use LoadLibrary() and GetProcAddress() yourself and then do whatever you want. If you call LoadLibrary with just the dll name, it uses the same algorithm as with the import library (current dir + PATH) -- if you pass a full path, it will use it.
COM uses this technique to load a DLL based on a full path to the DLL which is in the registry -- you could do this too without COM.
You could search for it in some other way besides the PATH -- you could call with no path, see if it finds it, and then try the registry, and then look elsewhere (every drive's program files directory, etc).
Basically, if you call LoadLibrary and GetProcAddress yourself, you can do whatever you want.
I guess that it would be best to install it into system32 folder and forget about %PATH% modification...
I have a question about getting DLL's directory on Windows system.
The situation is like this :
I have a DLL and an EXE file. The exe file must load the DLL to run.
These 2 modules are in different directories.
Moreover, the directory of the DLL is changeable.
Now I have to get the directory of the DLL in "run time".
How could I do this?
Thanks in advance.
Do you need to find where the DLL is to load it or find the the path where it was loaded from?
The DLL path search algorithm is documented on MSDN and you can use the SearchPath function to search the system path.
If you need to find the path where a DLL was loaded, after it was loaded, use the GetModuleFileName function. That takes the module handle that is returned by LoadLibrary, GetModuleHandle, or passed in as hinstDLL to DllMain and returns the full path to the DLL.
I guess you need to implement some custom search algorithm. Only your exe knows which one DLL is needed and where it can be. So find the path and use it with LoadLibrary().
BTW, if possible, I would consider using COM. In this way you will use DLL stuff by some CLSID, which is completely independent from file path.
On Linux/GCC I can use the -rpath flag to change an executables search path for shared libraries without tempering with environment variables.
Can this also be accomplished on Windows? As far as I know, dlls are always searched in the executable's directory and in PATH.
My scenario: I would like to put shared libraries into locations according to their properties (32/64bit/Debug/Release) without taking care of unique names. On Linux, this is easily be done via rpath, but I haven't found any way doing this on Windows yet.
Thanks for any hints!
Sadly there is no direct analogue to RPATH. There are a number of alternative possibilities, each of them most likely undesirable to you in its own special way.
Given that you need a different exe for each build flavor anyway to avoid runtime library clashes, as you might guess the easiest thing to do is to put each exe in the same folder as each set of DLLs.
As you also mentioned, the most universal method is to change the PATH variable by using a batch file to bootstrap the exe.
You could instead change the current working directory before running the program to the desired DLL folder.
You can use the function SetDllDirectory or AddDllDirectory inside your exe. This is probably the closest to an RPATH, but only works on WinXP SP1 or later.
If you're willing to alter the file name of each exe flavor, you can use the "App Paths" registry key. Each exe would need a unique filename.
The search order for DLLs in Windows is described on this page on MSDN. If you're using run-time dynamic linking, you can specify the folder when you call LoadLibrary.
"Isolated applications" is a mechanism for embedding an XML manifest that describes the DLL dependencies.