I am writing a DLL to plug into another (3rd party) application. The DLL will need to depend on another set of DLLs (for license reasons I cannot link statically).
I would like my DLL to be "xcopy-deployable" to any directory. I would also like not to require adding this directory to the path.
If I just build the DLL the usual way, Windows will refuse to load the DLL, since it cannot find the DLLs next to the current process.
Are there any good options for helping Windows locate the DLL?
To answer some questions:
The DLL is written in C++.
The extra DLLs are QT-dlls.
I would like to place the extra DLLs in the same folder as my plugin DLL. I can get the name of that folder from GetModuleFileName.
The application is Firefox, the DLL is a PKCS#11 security module.
The application loads the DLL using the full path to the DLL (the user supplies it when installing the plugin).
Requiring that the DLLs be placed in System32 or next to the application would work, but it is a bit messy and could cause problems with uninstallers.
LoadLibrary and GetProcAddress would of course work, but is not really feasible in my case. I am using hundreds, if not thousands, of methods in the other DLLs. I really need to use the import-libraries.
I had thought about using delay-loaded dlls combined with SetDllDirectory in DllMain. Have anyone tried anything like this?
I can think of 3 ways.
put the dlls in the same folder as your application (you cannot do this?)
Use runtime linking. LoadLibrary() and GetProcAddress()
Use a manifest http://msdn.microsoft.com/en-us/library/aa374182(VS.85).aspx
But if the dll isn't in the same folder as the .exe, how are you going to know where it is? forget Windows not knowing, how do you know?
you can specify the path of dll as the parameter of LoadLibrary().
Another option is to modify the PATH variable. Have a batch file for launching the main app, and set the PATH=%PATH%;%~dp0. This ensures a minimal footprint, with no additional traces left in the system after running.
Related
My basic issue is this: my program (MyProgram.exe) has a dependency on a DLL from another program (OtherProgram), and I'm trying to avoid repackaging a new DLL every time OtherProgram updates. I'd like to have MyProgram.exe link in OtherProgram's DLL when it launches, but I'm not completely sure that Windows allows for this. So if there is some kind of workaround that would also be acceptable.
And just for some background, the platform is Windows 7 x64, and MyProgram.exe runs fine when I create a symlink in the MyProgram.exe project directory to the DLL in OtherProgram's install directory. When I try to run it without the symlink, I get the "program can't start because OtherProgramDLL.dll is missing from your computer" error.
Any advice or links to relevant info is greatly appreciated!
EDIT: Clarification: the DLL is not linked at compile-time, this issue crops up at runtime
There are two types of dynamic linking in the Windows world:
Load-Time linking is when a DLL is loaded automatically when your program starts up. Windows finds this DLL using a specific algorithm I'll discuss below.
Run-Time linking is when you specifically load a DLL by calling LoadLibrary in your code. Similar rules apply as to how the library is found, but you can specify a fully-qualified or relatively-qualified path to control the search.
In the case of Load-Time linking, MS recommends that your program's DLLs are stored in and loaded from the same directory where your application is loaded from. If this is at all workable, this is probably your best option.
If that doesn't work, there are several other options, outlined here. One is to leverage the search order by putting the DLL in either the working directory or the directory where the application was loaded from.
You can change the working directory of an application by:
Create a shortcut to your application.
Bring up the shortcut's properties
Edit the "Start in" property with the directory where the DLL is located.
When you launch your application using the shortcut, it will load the right DLL.
Other options for load-time linking include:
Adding a manifest to your application which specifies where your dependent assemblies are, or,
Setting the PATH.
You could use LoadLibrary, but you would need a way to guarantee the DLL's location. This Wikipedia article provides good example on how to use the DLL after it has been loaded.
You can add the directory where the dll is located to the PATH environment variable.
I have struggled with the same problem and also found a dead end with the suggested methods like LoadLibrary, SetDllDirectory, Qt's addLibraryPath and others. Regardless of what I tried, the problem still remained that the application checked the libraries (and didn't find them) before actually running the code, so any code solution was bound to fail.
I almost got desperate, but then discovered an extremely easy approach which might also be helpful in cases like yours: Use a batch file! (or a similar loader before the actual application)
A Windows batch file for such a purpose could look like this:
#echo off
PATH=%PATH%;<PATH_TO_YOUR_LIB>
<PATH_TO_YOUR_APP_EXE>
/edit: Just saw #SirDarius comment in Luchian's answer which describes that way, so just take my batch code bit as a reference and all credits go to him.
I have the same problem with one application I am working on.
I do not want to use runtime loading because there are tens of functions I would need to manually create function pointer for.
Mr Dibling's mention of manifest file opened a new door for me but I sadly found out that the oldest version of windows that supports the feature is Windows 7. It won't even work on Vista.
Long story short, a friend familiar with Windows Application development told me to look up Delay-Loaded DLL, which turns out to solve the problem perfectly with minimal effort. It delays the loading of DLL library to either the point you manually do, or the first time its function is called. So you just need to add your DLL path to the search path before that happens, where SetDllDirectory helps.
Here is the steps to make it work:
1) Specify the DLL to be delay-loaded to linker, either through your makefile, cmake or VS property page (Linker->Input of VS2015)
2) Call SetDllDirectory at the beginning of your program, before any call to the DLL is made.
Delay-loaded DLL is supported all the way back to VC6.
SetDllDirectory is supported after XP SP1.
Use Symbolic Links to the 3rd Party Executables
I found the approach advocated by Aaron Margosis useful. See:
Using NTFS Junctions to Fix Application Compatibility Issues on 64-bit Editions of Windows
Essentially, create symbolic links to each of the dependent 3rd Party executables. Place these symbolic link files in and amongst your own dependent executable files. Except for filename changes to the targets, the 'soft' symbolic links will resolve the load-time dependencies even as the target of the links are changed by future updates.
I have successfully divided a large MFC project into a couple of smaller DLL projects. Now I want to have a separate folder called "DLL" in my application's folder, where all the all the DLLs from the subprojects are placed.
Can anybody give me guidance in how to achieve this?
If you use LoadLibrary, you simply have to explicitly specify the full path of the DLLs you load.
If the DLLs are implicitly linked, you can do this in two ways.
Have the installer modify the PATH variable. This is intrusive and "bad form"
Write a "loader" application that locally modifies the path variable, then executes the real executable.
The best solution would be to simply put the DLLs in the same directory as the executable.
DLL redirection is a fairly new feature (Windows 2000 IIRC). Name your DLL directory <myapp>.exe.local, and Windows will check it first for anything loaded via LoadLibrary(Ex). This includes delay-loaded DLLs.
EDIT: As pointed out by Eric this doesn't work. Sorry.
See Dynamic-Link Library Search Order. In short you can do so using registry keys under the "HKEY_LOCAL_MACHINE\SORTWARE\Microsoft\Windows\CurrentVersion\App Paths" key.
A reg file like the following shows how:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MyApp.exe]
#="C:\\Program Files\\MyCompany\\MyApp\\MyApp.exe"
"Path"="C:\\Program Files\\MyCompany\\MyApp\\MyDLLs"
My application uses one version of library (a.dll), I am using another DLL(b.dll) which in-turn uses older version of the same library (a.dll) that i use. I am building the application by embedding a manifest file. The DLL i use is also using a embedded manifest file. I am having both the versions of the library in my WinSXS folder. My application is not able to load the appropriate versions of DLLs.
Will having a separate manifest file (not embedding into DLL) help resolving the problem? What is the work around?
Your situation is exactly the situation WinSxS is supposed to solve. It should be working.
Either: The manifest files are pointing to the same version, or one of the manifest files is not embedded properly, or
The shared assembly in WinSxS was installed with a configuration policy that automatically redirects requests for v1.0 to v1.1
Some clarifications are needed: App.exe and b.dll are implicitly linked against a.dll? Or do they load it via LoadLibrary.
If B.DLL loads A.DLL explicitly using LoadLibrary then you need to add ISOLATION_AWARE_ENABLED to your pre-processor definitions to ensure that LoadLibrary calls made by B.DLL look in the correct activation context. Otherwise they will be made in the context of the default activation context which was created by the EXE's manifest.
It will depend on what the duplicated DLLs do and if their versions are compatible. (e.g. Do they both access shared objects in memory? If so, there's a good chance something will blow up.)
It will also depend on how those two same-named DLLs are loaded. If it's anything other than an explicit LoadLibrary with a full path then things probably will not work. There's an ongoing discussion of this here: Determine the loaded path for DLLs
In general, it might work if you're lucky. The fact it may go catastrophically wrong is a good reason to avoid the issue entirely, if you can. (In the worst case, you could host one of the modules in another process and proxy all the calls to it. Ideally, just be able to use the same DLL version in both modules.)
I am working on a Qt DLL that is used as a plugin for a large application. This DLL depends on other DLLs that are sadly not located in the same folder and hence will only load if the current working directory has been set correctly (which the large application does prior to calling LoadLibrary on the DLL). I have no control over this behaviour.
I have been asked to add a simple COM object to this plugin which I have done but I now have the problem that the DLL cannot be registered or used by a 3rd-party application unless the current working directory is set correctly - because any LoadLibrary calls on the plugin fail due to the missing dependencies. Obviously I have no control over the current working directory used by 3rd-party apps and at this stage I am not allowed to modify the PATH to ensure the dependencies can be found.
I have tried using /DELAYLOAD for the dependent DLLs but this fails with 'cannot delay-load foo.dll due to import of data symbol...' errors. Again, I cannot easily change the way these dependent DLLs are used.
Currently I think the only solution is to move the COM object into a stand-alone DLL that doesn't depend on anything else but I am under pressure to find a solution and leave the COM object in the plugin DLL. I can't see how this is possible so I thought I'd see if anyone else has any ideas. Some form of system-wide SetDllDirectory call would help or some registry hack that could set the working directory when a 3rd-party app calls LoadLibrary on my plugin.
IMO separating the COM object into a separate .dll is the cleanest solution - anyone would expect an in-proc COM server to be registered by using regsvr32 and that requires no fancy dependencies in that COM server.
I don't know if it's precisely a solution to your problem, but maybe this can help you: try to look at the possibilities offered by manifest files. I hope it will help.
You could use a runtime registration model.
The Dll could register itself as a COM server in its own initialisation code.
This only requires that loadlibrary is guaranteed to be called before the dll is used as a COM server.
I have a C++ Exe in an application directory which contains the DLLs used by it. Now, for some testing purpose I need to modify an existing DLL and use that instead of the original one. But in order to not modify the existing installation I cannot backup the existing DLL and replace it with the modified one or move the existing one elsewhere. I also cannot change the Exe. The 2 DLLs need to exist side by side. The only change should be that the Exe should transparently load the modified DLL which is in some other folder rather than the existing DLL which is in the same folder as the Exe. Is there some elegant way of doing it?
I looked at some MSDN articles but could not find a way of doing this. The solution should work on Windows XP and up.
Windows will load at most one version of each DLL name per process. If it loads a DLL listed in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs, it won't load a similarly-named DLL later. But in AppInit_DLLs you can list a DLL with an explicit path, overriding the normal LoadLibrary() order.
Hence, temporarily put your test DLL in AppInit_DLLs and it will override any other DLL with the same name.
According to MSDN, it will always start by the application directory (unless you modify it with the alternate search order method...) so it seems to be difficult. You can still copy the executable and its other dependencies elsewhere. It is not that elegant though.
Or you can launch the executable that you have copied elsewhere along with the new DLL, from the original directory. According to the search order it should work too, though I must admit I have never tried.
You can hook LoadLibrary() calls for your process from the beginning. When your patched version of LoadLibrary() sees your DLL's it calls original LoadLibrary() with modified DLL's path.Even if you don't use LoadLibrary() call to load your DLLs, Windows CRT does. So this technique must work.
The only way I know would use LoadLibrary API including the path, but you say you can not change the exe.