我可以在同一个进程中使用两个不兼容的DLL版本吗?

我使用两个由同一供应商生产的商业库,称为VendorLibA和VendorLibB。 这些库分发尽可能多的依赖于编译器版本的DLL(例如VC7,VC8)。 两个库都依赖于另一个由该供应商生产的库,名为VendorLibUtils,并包含在一个DLL中。

问题:VendorLibA使用与VendorLibB不同版本的VendorLibUtils。 这两个版本不是二进制兼容的,即使是这样,使用错误的版本也是一个坏主意。

有什么办法可以在同一个进程下使用这两个库吗?

注意: LoadLibrary无法解决这个问题,因为我的stream程并不是导入VendorLibUtils的stream程。

编辑:忘了提起明显的,我没有任何商业图书馆的源代码,可能我永远不会( 叹气 )。

编辑:另一个顺便说一句,是这样做的: 如何在Windows中结合GUI应用程序

Solutions Collecting From Web of "我可以在同一个进程中使用两个不兼容的DLL版本吗?"

由于您不直接使用VendorLibUtils,我假设您不能使用LoadLibrary等。

如果VendorLibUtils DLL仅按顺序导出,则可以重命名其中一个库并修补相应的VendorLib X ,以便为其导入使用不同的文件名。

如果VendorLibUtils DLL具有一个或多个具有相同名称的导出符号,则可能还需要修补导入和导出表,但是不要希望! 🙂

我认为你最有希望的选择是大声抱怨分销互不相容产品的供应商。 这反而违背了DLL的想法。

你不能把这些DLL放在不同的目录下。 一旦具有给定名称的DLL被加载,所有其他尝试加载具有相同模块名称的另一个DLL将简单地使用已加载的DLL,即使路径不同。

从这一点,我们可以得出结论,要加载VendorLibUtils的两个副本,一个副本需要有一个不同的名称。 你不能只重命名DLL文件; 您的程序中的代码将不知道要查找不同的文件。 因此,也许有办法编辑VendorLibB的导入表,使其认为它需要的功能在VendorLibUtilsB.dll而不是VendorLibUtils.dll。 恐怕我不知道会有这样做的效用,但我毫不怀疑这是可以做到的。

我有一个类似的问题。 具体而言,我想从嵌入在使用Qt不兼容版本的应用程序中的Python解释器中使用PyQt。 主应用程序使用了两个Qt DLL:QtCore.dll和QtGui.dll。

当我从嵌入式Python解释器加载PyQt时,会出现一个错误:

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

这发生在线上:

 from PyQt4 import QtGui 

问题是一旦不兼容的QtGui.dll被加载到主应用程序的进程空间中,任何对QtGui.dll的引用(例如从文件QtGui.pyd)都是不正确的。

接下来发生的事情,我并不感到自豪。

首先,我将PyQt发行版中的QtGuiX.dll重命名为QtGuiX.dll ,然后将QtCore4.dll重命名为QtCoreX.dll 。 请注意,重命名保持相同数量的字符,这很重要。

接下来,我在Notepad ++中打开了QtGui.pyd文件, QtGui.pyd所有纯文本引用QtGui4.dllQtGuiX.dll并将其从QtCore4.dllQtCoreX.dll 。 我重复了文件的过程: QtCore.pydQtGuiX.dllQtCoreX.dll

最后,我检查了我的PyQt测试应用程序仍然工作。 它做了! 然后,我尝试从嵌入式Python解释器运行PyQt测试应用程序,并且工作得很好。

所以,这似乎适用于一些微不足道的情况。 我期望我需要重复PyQt分发中的所有DLL和PYD的过程。

这可能不是正确的做法,但我想不出有什么具体的原因可能会炸毁(除了如果我改变文件名的长度)。

信任(或责备)给其他人的线索来鼓舞这个可怕的故事。

我不是DLL的专家,但我认为可能的唯一方法是使用LoadLibrary()并显式加载DLL。 然后你可以使用GetProcAddress()将函数/类等放在不同的名字空间中。

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

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

不管这个工作是否有效还是取决于图书馆,所以它可能工作也可能不工作,但据我所知,这是唯一的可能性。

正如别人提到的,您可以重命名VendorLibUtils的一个副本,并修改关联的VendorLib DLL的导入表以链接到它,而不是它创建的VendorLibUtils.dll。

有几个工具可以让你用这种方式编辑EXE / DLL文件。 CFF资源管理器是一个相当不错的,允许编辑导入表。 如果打开VendorLib DLL并转到导入目录部分(在左边的树中),你会看到主窗口顶部的模块列表。 您可以通过双击其名称来重命名该模块。 然后,您只需保存DLL,它现在应该使用您的重命名的VendorLibUtils DLL。

当然,这里假设VendorLib使用导入表访问VendorLibUtils,它可能不使用LoadLibrary / GetProcAddress ,在这种情况下,您将看不到VendorLibUtils的导入表项。

实际上,如果VendorLib确实使用了导入表,而且在某些地方使用LoadLibrary来访问VendorLibUtils DLL(我已经看到了),那么这些地方仍然会使用错误的地方。 如果您重命名这两个库,则至少可以看到一个错误(因为具有原始名称的DLL现在不存在)。 如果发生这种情况,有办法解决这个问题,但是现在开始变得相当复杂,所以除非你真的想/需要知道,否则我不会详细说明。

你的意思是,你有类似于MSVCRT80.DLL和MSVCRT90.DLL的情况? 微软对这些DLL进行编号有一个很好的理由。如果两者都被称为MSVCRT.DLL,则只有其中一个会被加载到一个进程中。

实际上可以隐式地将不同版本的dll加载到单个进程中。

这样做需要:

  1. 创建两个程序集,每个包含必须多次加载的dll版本。 听起来很复杂,但实际上它只需要创建(2)命名的子文件夹,每个文件夹都包含一个包含一些xml的.manifest文件,以及它自己的dll副本。 那么,VendorUtilsAssemblyV1和VendorUtilsAssemblyV2

  2. 使每个依赖dll使用汇编机制来解决隐式依赖 – 通过添加显式标识VendorUtilsAssemblyV1或V2的assemblyDependency指令。

点2有一些选项。如果VendorLibA和VendorLibB文件不包含自己的清单,那么您可以简单地添加名为VendorLibA.2.dll.manifest和VendorLibB.2.dll.manifest的必需dependentAssembly指令的清单文件。 如果他们已经包含清单(可能链接到VS2005或VS2008 C运行时),然后使用MT.EXE工具合并到新的依赖项中。