为什么64位的dll会转到System32，而32位的dll会转到SysWoW64 ?

我想知道我们什么时候需要把一个文件放在

C:\Windows\ system32或C:\Windows\SysWOW64，在64位windows系统上。

我有两个DLL，一个32位，一个64位。

逻辑上，我认为我应该将32位DLL放在C:\Windows\System32下，而64位DLL放在C:\Windows\ syswow64下。

令我惊讶的是，它是反过来说!32-bit DLL进入C:\Windows\SysWOW64，而64-bit DLL进入C:\Windows\System32。

非常令人困惑。背后的原因是什么?

188275 次浏览
小开
最佳答案

我相信其目的是重命名System32，但是许多应用程序都为该路径硬编码，因此不可能删除它。

SysWoW64并不是为64位系统的dll设计的，它实际上有点像“windows64上的Windows”，意思是你需要在64位窗口上运行32位应用程序。

这篇文章解释了一点:

Windows x64有一个包含64位dll的目录System32。 因此比特位为64的本机进程在以下位置找到“它们的”dll 在System32文件夹中。第二个目录， SysWOW64，包含32位的dll。文件系统重定向器可以 为32位进程隐藏真实System32目录的魔力 在System32的名称下显示SysWOW64 .

如果你在谈论一个安装程序，你真的< >强不应< / >强硬编码到系统文件夹的路径。相反，根据您的安装程序是否运行在模拟层上，让Windows为您处理它。

小开

我应该补充:你不应该把你的dll文件放在\system32\无论如何!修改你的代码，修改你的安装程序…为你的比特找一个不是在c:\windows\下的地方

例如，你的安装程序把你的dll放入:

\program files\<your app dir>\


or


\program files\common files\<your app name>\

(请注意: 你实际做这件事的方法是使用环境var: %ProgramFiles% or %ProgramFiles(x86)%来查找ProgramFiles是....你不假设它是c:\program files\ ....)

然后设置一个注册表标签:

HKLM\software\<your app name>
-- dllLocation

使用dll的代码读取注册表，然后动态链接到该位置的dll。

以上是明智的做法。

不要将自己的dll或第三方dll安装到\system32\或\syswow64中。如果你必须静态加载，你把你的dll放在你的exe目录下(在那里可以找到它们)。如果你不能预测exe的目录(例如，其他exe将调用你的dll)，你可能不得不把你的dll目录放入搜索路径(避免这一点，如果在所有poss!)

system32和syswow64是Windows提供的文件…其他人的文件都不行。人们养成把东西放在那里的坏习惯的唯一原因是，它总是在搜索路径中，许多应用程序/模块使用静态链接。(所以，如果你真的认真对待它，真正的罪过是静态链接——这是原生代码和托管代码的罪过——总是总是总是动态链接!)

小开

遇到同样的问题，我研究了几分钟。

我被教导使用Windows 3.1和DOS，还记得那些日子吗?在我严格使用Macintosh电脑一段时间后不久，在买了一台x64位电脑后，我又开始转向Windows。

这些变化背后有实际的原因(有些人会说是历史意义)，这对程序员继续他们的工作是必要的。

上面提到了大部分变化:

  • Program Files vs Program Files (x86)

    最初，16/86位文件是写在'86'英特尔处理器上的。 < / p >

  • System32的意思是System64(在64位Windows上)

    当开发人员第一次开始使用Windows7时，在存储其他应用程序时存在一些兼容性问题

  • SysWOW64真正的意思是SysWOW32

    本质上，在简单的英语中，它意味着“64位计算机中的Windows on Windows”。每个文件夹都指明了应用程序希望使用dll的位置

这里有两个链接，上面有你需要的所有基本信息:

希望这能把事情弄清楚!

小开
System32是Windows历史上放置所有32位dll的位置，而System是16位dll的位置。当微软创建64位操作系统时，我认识的每个人都希望文件驻留在System64下，但微软决定将64位文件放在System32下更有意义。我能找到的唯一理由是，他们希望所有32位的东西都能在64位的Windows上运行，而不需要改变程序中的任何东西——只是重新编译，然后就完成了。他们解决这个问题的方法是在Windows64上创建一个名为Windows32的32位窗口子系统，这样32位应用程序仍然可以运行。因此，为32位子系统的System目录创建了首字母缩写SysWOW64。“Sys”是System的缩写，“WOW64”是Windows32OnWindows64的缩写 因为windows 16已经从windows 32中分离出来了，所以没有必要在windows 64上设置一个对等的windows 16。在32位子系统中，当程序使用system32目录中的文件时，它们实际上是从SysWOW64目录中获取文件。但是这个过程是有缺陷的

这是一个可怕的设计。根据我的经验，为了编写64位应用程序，我必须做更多的更改，简单地将System32目录更改为读取System64将是一个非常小的更改，而且是预编译器指令打算处理的。

小开

其他人已经很好地解释了这个荒谬的难题……我认为Chris Hoffman在这里做得更好:https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows/

我有两个想法:

  1. 我们在生活中都会犯愚蠢的短视错误。当微软将他们(当时)的Win32 DLL目录命名为“System32”时，这在当时是有意义的…他们只是没有考虑到如果64位(或128位)版本的操作系统后来被开发出来会发生什么——以及这样的目录名会导致大量的向后兼容性问题。事后诸葛亮总是20-20，所以我真的不能责怪他们(太多)这样的错误. ...然而…当微软后来开发了他们的64位操作系统时，即使是事后的好处，为什么哦，为什么他们不仅再次犯同样的短视错误，而且故意给它起这样一个误导性的名字，使它变得更糟?!?他们真可耻!!为什么不至少将目录命名为“SysWin32OnWin64”以避免混淆?!?当他们最终生产出128位的操作系统时会发生什么?那么他们将把他们的32位、64位和128位dll放在哪里?!?

  2. 在我看来，所有这些逻辑都是有缺陷的。在32位版本的Windows上，System32包含32位dll;在64位版本的Windows上，System32包含64位dll…这样开发人员就不必修改代码了，对吗?这种逻辑的问题在于，这些开发者现在要么制作64位应用需要64位dll，要么制作32位应用需要32位dll……不管怎样，他们不是完蛋了吗?我的意思是，如果他们仍然在制作一个32位的应用程序，为了让它现在在64位的Windows上运行，他们现在需要做一个代码更改来找到/引用他们以前使用的相同的32位DLL(现在位于SysWOW64)。或者，如果他们正在开发一个64位的应用程序，他们无论如何都需要为新的操作系统重写旧的应用程序……所以无论如何都需要重新编译/重建!!

微软有时会伤害我。


提交答案