Visual studio 2015 64位属性表使用32位winapi DLL

我用vs2015转换了一个旧的visual studio项目，并添加了64位平台配置

我想知道为什么链接器属性包含32位lib（比如kernel32.lib；user32.lib；gdi32.lib；winspool.lib；comdlg32.lib；advapi32.lib；shell32.lib；ole32.lib；oleaut32.lib）

首先，我认为这是我的一个错误，因为我选择从win32平台设置复制设置，但后来我看到此设置是由studio插入的属性表导入的：“Microsoft.Cpp.x64.user”

这真的是这样吗？我在某个地方读到（这里是SO:）64位应用程序无法链接到32位DLL

---

有人能告诉我吗？

这些DLL名称可以追溯到23年前Windows的第一个32位版本发布时。Windows版本1到3为16位，使用kernel.dll、user.dll等。他们在DLL名称后粘贴“32”，以区别于16位版本，并确保32位进程不会意外加载16位DLL

他们在发布64位版本的Windows时没有再这样做。到那时，有太多的程序硬编码这些名称，通常是在LoadLibrary（）调用中，更改名称会使这些程序很难移植到64位。即使存储这些DLL的目录也没有重命名，它仍然是“system32”

因此，一台机器现在有两个kernel32.dll等的副本，64位版本位于c:\windows\system32，32位版本位于c:\windows\syswow64。仍然非常重要的是，32位进程从不尝试加载64位DLL，反之亦然，就像23年前一样重要。因此他们想出了另一个窍门，确保32位进程只能在syswow64中看到副本

请注意，在名为“system32”的目录中有64位DLL，而在“syswow64”中有32位DLL，这很奇怪。一开始会让很多程序员大吃一惊，现在你知道这是怎么发生的了

---

与.lib文件大致相同，SDK目录有一个x86和一个x64目录来存储这些文件。链接器在项目>属性>VC++目录>库目录中配置.lib文件，这也是非常自动的。Win32/x86平台目标使用$（WindowsSDK\u LibraryPath\u x86），x64目标使用$（WindowsSDK\u LibraryPath\u x64）

啊-好的-我明白了。我还对依赖性walker（2.1.xx）感到恼火，它显示exe是64位的，但依赖的DLL不是。在更新版本（2.2.xxx）中，依赖项也被标记为64位-与它们的名称相反（正如您所解释的）