Windows：构建同一DLL的32位和64位版本

Question

作为新合同职位培训的一部分，我的任务是建立两个DLL和两个cppunit单元测试程序。 一切都成功构建。

当我尝试运行一个单元测试程序时，我发现两个DLL（由单元测试程序使用）都混合了32位和64位元素。 我下载了Dependency Walker（Depends.exe），并跟踪DLL获取其输入的问题。 32位库位于C：\\ AppName \\ bin目录中，而64位库位于C：\\ AppName \\ bin64中。

由于直到运行时（实际上是加载时间）才会加载DLLS，并且由于DLL与.exe不在同一目录中，并且由于PATH将这两个文件夹的搜索顺序显示为“ C：\\ AppName \\ bin64; C”，因此：\\ AppName \\ bin;“，当我尝试运行单元测试时，出现一个错误，告诉我有64位模块与32位模块混合在一起，并拒绝运行。 我通过将bin64重命名为SAVE_bin64来解决此问题，以便加载程序将找不到它，默认为其他目录，并加载正确的DLL。

我的办公室伴侣也接受了同样的任务。 他没有这样的困难。 不仅如此，而且我以前已经使程序成功运行，但是在使用公司安装工具安装了某些模块后遇到了问题。 由于安装是在后台进行的，所以我不知道它做了什么，除了愚弄我的构建之外。

Visual Studio C ++（非托管）生成过程中的某些内容已将足够的信息包含到.exe中，以使加载程序知道在哪里可以找到正确的DLL，但是在执行安装时却大失所望。

在最终通过在Depends.exe中打开“完整路径”来找出原因之前，我对此问题进行了广泛的研究，因此我已经了解了SxS（并排）和DLL重定向，在此两者都不相关。

因此，问题是，Windows加载程序如何一次找到了正确的DLL，而又没有找到？ 加载程序如何在他的计算机上找到正确的DLL，但不是我的？

提前致谢。

编辑添加：

我又尝试了一个实验。 我的bin64仍重命名为SAVE_bin64，我将两个库（libB.dll依赖于libA.dll）和单元测试程序（都依赖于libB.dll）构建为32位。 然后，我将SAVE_bin64重命名为bin64，这样，如果加载程序完全依赖PATH变量来定位依赖的DLL，则由于32/64位不匹配，单元测试程序将无法运行。 但是，运行了单元测试程序，成功地在72个模块中发现了一个错误。

这说明Visual Studio 2010 C ++编译器/链接器能够以某种方式将相关DLL的正确位置嵌入到可执行程序中，从而使加载程序不必依赖PATH变量来查找DLL。

Answer 1

这可能有助于理解Windows如何搜索dll：
MSDN：动态链接库搜索顺序

加载程序将选择其名称匹配的第一个（在搜索列表中）它首先看到的dll。 DLL是64位还是32位都没有关系。 我可以肯定的是，如果它是一个重命名为.dll的文本文件，它甚至会尝试加载它。也许您的同事在系统文件夹中拥有他的dll，或者与应用程序版本并列。

我发现一种简单的处理方法是为32位和64位的dll使用不同的名称。 example32.dll和example64.dll。