我使用vs2015转换了一个旧的visual studio项目并添加了64位平台配置。
我想知道为什么链接器属性确实包含32位libs（如kernel32.lib; user32.lib; gdi32.lib; winspool.lib; comdlg32.lib; advapi32.lib; shell32.lib; ole32.lib; oleaut32.lib ）。
首先我认为这是我的错误，因为我选择从win32平台设置中复制设置，但后来我看到这些设置是由工作室插入的属性表导入的：＆＃34; Microsoft .Cpp.x64.user＆＃34;
这真的是这个应该如何运作的方式吗？我在某地（在这里：Can a 64 bit EXE link against 32-bit DLLs?）读到64位应用程序无法链接到32位dll。
可以给我启发吗？
答案 0 :(得分：4)
这些DLL名称可追溯到23年前，当时发布了第一个32位版本的Windows。 Windows版本1到3是16位并使用kernel.dll，user.dll等。他们粘合了＃32; 32＆＃34;在DLL名称之后，将它们与16位版本区分开来，并确保32位进程无法意外加载16位DLL。
当他们发布64位版本的Windows时，他们没有再这样做。到那时，太多程序对这些名称进行了硬编码，通常是在LoadLibrary（）调用中，并且更改名称会使将这些程序移植到64位太困难。甚至没有重命名存储这些DLL的目录，它仍然是＆＃34; system32＆＃34;。
因此，一台机器现在有两份kernel32.dll等，64位版本位于c：\ windows \ system32，而32位版本位于c：\ windows \ syswow64。仍然非常重要的是，32位进程永远不会尝试加载64位DLL，反之亦然，就像它在23年前重要一样。所以他们提出了另一个技巧，File System Redirector确保32位进程只能在syswow64中看到副本。
请注意在名为＆＃34; system32＆＃34;的目录中使用64位DLL的奇怪之处。和＃34; syswow64＆＃34;中的32位DLL。最初尝试许多程序员，现在你知道发生了什么。
.lib文件大致相同，SDK目录有一个x86和一个x64目录来存储这些文件。同样非常自动，链接器查找.lib文件是在Project＆gt;中配置的。属性＆gt; VC ++目录＆gt;图书馆目录。 Win32 / x86平台目标使用$（WindowsSDK_LibraryPath_x86），x64目标使用$（WindowsSDK_LibraryPath_x64）。