Can I use two incompatible versions of the same DL

问题:

I'm using two commercial libraries that are produced by the same vendor, called VendorLibA and VendorLibB. The libraries are distributed as many DLLs that depend on the compiler version (e.g. VC7, VC8). Both libraries depend on a another library, produced by this vendor, called VendorLibUtils and contained in one DLL.

The problem: VendorLibA uses a different version of VendorLibUtils than VendorLibB. The two versions are not binary compatible, and even if they were it would be a bad idea to use the wrong version.

Is there any way I could use the two libraries under the same process?

Note: LoadLibrary can't solve this since my process is not that one that's importing VendorLibUtils.

EDIT: Forgot to mention the obvious, I don't have to source code for any of the commercial libraries and probably I will never have (sigh).

EDIT: The alternative btw, is to do this: How to combine GUI applications in Windows

回答1:

As you are not using VendorLibUtils directly, I assume you can't use LoadLibrary etc.

If the VendorLibUtils DLLs only have exports by ordinal, you could probably rename one of the the libraries and patch the corresponding VendorLibX to use a different filename for its imports.

If the VendorLibUtils DLLs have one or more exported symbols with the same names, you might need to patch the imports and export tables too, but let's hope not! :-)

回答2:

I think your most promising option is to complain, loudly, to the vendor who is distributing mutually incompatible products. That rather goes against the idea of a DLL.

You can't just put the DLLs in different directories. Once a DLL with a given name is loaded, all other attempts to load another DLL with the same module name will simply use the one that's already loaded, even if the paths are different.

From that, we can conclude that to load two copies of VendorLibUtils, one copy needs to have a different name. You can't just rename the DLL file; the code in your program won't know to look for the different file. Therefore, perhaps there's a way to edit the import table of VendorLibB to make it think the functions it needs are in VendorLibUtilsB.dll instead of just VendorLibUtils.dll. I'm afraid I don't know of any utility that will do that, but I have little doubt it's possible to do.

回答3:

I had a similar problem. Specifically I wanted to use a PyQt from a Python interpreter embedded in an application that was using an incompatible version of Qt. There were two Qt DLLs used by the primary application: QtCore.dll and QtGui.dll.

When I would load PyQt from the embedded Python interpreter, I would get an error:

ImportError: DLL load failed: The specified procedure could not be found.

This occured on the line:

from PyQt4 import QtGui

The problem is that the once an incompatible QtGui.dll is loaded into the main application's process space any references to QtGui.dll (e.g. from the file QtGui.pyd) are incorrect.

What happened next, I am not proud of.

First I renamed QtGui4.dll in the PyQt distribution to QtGuiX.dll and then renamed the QtCore4.dll to QtCoreX.dll. Notice that the renaming maintained the same number of characters, this is important.

Next I opened the file QtGui.pyd in Notepad++, and replaced all plain-text references of QtGui4.dll to QtGuiX.dll and from QtCore4.dll to QtCoreX.dll. I repeated the process for the files: QtCore.pyd, QtGuiX.dll and QtCoreX.dll.

Finally I checked that my PyQt test application still worked. It did! Then I tried running the PyQt test application from the embedded Python interpreter, and it worked as well.

So, it seems to works in a couple of trivial cases. I expect that I need to repeat the process for all DLLs and PYDs in the PyQt distribution.

This is probably not the right way to do things, but I can't think of any concrete reasons how it could blow up (other than if I change the length of the file name).

Credit (or blame) to others on the thread for inspiring this terrible tale.

回答4:

I'm no expert in DLLs, but the only way I see it possible would be to use LoadLibrary() and explicitly load the DLLs. Then you could place the functions/classes etc in separate namespaces using GetProcAddress().

HMODULE v1 = LoadLibrary(_T("libv1_0.dll"));
libv1_0::fun_in_lib = reinterpret_cast<FUNTYPE>(GetProcAddress(v1, _T("fun_in_lib"));

and

HMODULE v2 = LoadLibrary(_T("libv2_0.dll"));
libv2_0::fun_in_lib = reinterpret_cast<FUNTYPE>(GetProcAddress(v2, _T("fun_in_lib"));

Whether this would work or not still kind of depends on the library, so it may or may not work, but as far as I can tell it's the only possibility.

回答5:

As someone else mentioned, you could rename one of the copies of VendorLibUtils and modify the import table of the associated VendorLib DLL to link to it, rather than the VendorLibUtils.dll it was created with.

There's a few tools out there that let you edit EXE/DLL files in this way. CFF Explorer is a pretty decent one which allows editing of the import table. If you open up the VendorLib DLL in it and go to the Import Directory section (in the tree on the left), you'll see a list of modules at the top of the main window. You can rename the module by double-clicking on its name. Then you just save the DLL and it should now use your renamed VendorLibUtils DLL.

Of course, this assumes that VendorLib uses the import table to access VendorLibUtils, which it may not -- it may use LoadLibrary/GetProcAddress, in which case you won't see an import table entry for VendorLibUtils.

Actually, if the VendorLib does use the import table but also uses LoadLibrary to access the VendorLibUtils DLL in some places (I've seen it done), those places will still use the wrong one. If you rename both libraries, you might at least see an error if this is the case (since a DLL with the original name won't exist now). There is a way to deal with this if it occurs, but it starts to get quite complicated at this point, so I won't elaborate unless you really want/need to know.

回答6:

You mean, you have a situation similar to MSVCRT80.DLL and MSVCRT90.DLL ? There is a good reason Microsoft numbered these DLLs.If both were called MSVCRT.DLL, only one of them would be loaded in a single process.

回答7:

It is actually possible to implicitly load different versions of a dll into a single process.

Doing this entails:

1. Creating two assemblies, each containing a version of the dll that must be loaded multiple times. Sounds complicated but practically it entails little more than creating (2) named sub folders, each with a .manifest file containing some xml, and its own copy of the dll. So, VendorUtilsAssemblyV1 and VendorUtilsAssemblyV2

2. Making each dependent dll use the assembly mechanism to resolve the implicit dependency - by adding a assemblyDependency directive that explicitly identifies VendorUtilsAssemblyV1 or V2.

There are some options for point 2. If the VendorLibA and VendorLibB files do not contain their own manifests, then you can simply add manifest files with the required dependentAssembly directive named VendorLibA.2.dll.manifest and VendorLibB.2.dll.manifest. If they already contain manifests (probably to link to the VS2005 or VS2008 C-Runtime) then use the MT.EXE tool to merge in the new dependency.