为什么在64位Windows上，将64位DLL转到System32，将32位DLL转到SysWoW64？

我想知道我们什么时候需要在下面放置文件

在64位Windows系统上为C：\ Windows \ System32或C：\ Windows \ SysWOW64。

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

从逻辑上讲，我想将32位DLL放在C：\ Windows \ System32下，并将64位DLL放在C：\ Windows \ SysWOW64下。

令我惊讶的是，它正好相反！的32位一个进入C：\的Windows \ SYSWOW 64，和64位DLL进入C：\的Windows \系统32。

非常令人困惑的东西。这是什么原因呢？

我相信其目的是重命名System32，但是有很多应用程序对该路径进行了硬编码，因此删除它是不可行的。

SysWoW64不适用于64位系统的dll，它实际上类似于“ Windows on Windows64”，这意味着在64位Windows上运行32位应用程序所需的位。

本文介绍了一下：

“ Windows x64的目录System32包含64位DLL（如此！）。因此，位数为64的本机进程在其期望的位置找到“其” DLL：在System32文件夹中。第二个目录SysWOW64包含32个文件系统重定向器神奇地隐藏了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％或％ProgramFiles（x86）％查找Program Files的位置。 ..）

然后设置一个注册表标记：

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

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

以上是明智的做法。

您永远不会将dll或第三方dll安装到\ system32 \或\ syswow64中。如果必须静态加载，可以将dll放在exe目录中（可以在其中找到它们）。如果您无法预测exe目录（例如，其他某个exe将调用您的dll），则可能必须将dll目录放入搜索路径（如果可能，请避免这样做！）

system32和syswow64适用于Windows提供的文件... 不适用于其他人的文件。人们习惯于将东西放在那里的坏习惯的唯一原因是，它总是在搜索路径中，并且许多应用程序/模块都使用静态链接。（因此，如果您真正了解它，真正的缺点就是静态链接-这是本机代码和托管代码中的缺点-始终始终总是动态链接！）

遇到相同的问题并对此进行了几分钟的研究。

我曾被教过使用Windows 3.1和DOS，还记得那些日子吗？在我严格地使用Macintosh计算机一段时间后不久，在购买x64位计算机之后，我又开始摇摆回Windows。

这些更改背后有一些实际原因（有些人会说具有历史意义），这对于程序员继续工作是必要的。

上面提到了大多数更改：

• Program Files 与 Program Files (x86)

  最初，16/86位文件是在“ 86”英特尔处理器上编写的。

• System32真的意味着System64（在64位Windows上）

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

• SysWOW64 真正意思 SysWOW32

  本质上，用通俗的英语来说，它意味着“ 64位计算机上的Windows on Windows”。每个文件夹都指示DLL所希望使用的应用程序的位置。

这是两个链接，其中包含您需要的所有基本信息：

• MSDN文件系统重定向器

• SysWow64解释

希望这可以清除一切！

Windows历史上一直在System32中放置所有32位DLL，而System用于16位DLL。当Microsoft创建64位操作系统时，我认识的每个人都希望文件位于System64下，但是Microsoft认为将64位文件放在System32下更有意义。我能够找到的唯一理由是，他们希望32位的所有内容都可以在64位Windows中工作，而无需更改程序中的任何内容-只需重新编译即可。他们解决此问题的方法（以便仍可以运行32位应用程序）是在Windows64上创建一个称为Windows32的32位Windows子系统。因此，为32位子系统的System目录创建了首字母缩写SysWOW64。Sys是System的缩写，而WOW64是Windows32OnWindows64的缩写。
由于Windows 16已经与Windows 32隔离，因此不需要Windows 16与Windows 64等效。在32位子系统中，当程序使用system32目录中的文件时，它们实际上是从SysWOW64目录中获取文件的。但是这个过程是有缺陷的。

这是一个可怕的设计。以我的经验，我不得不对编写64位应​​用程序进行许多更改，仅更改System32目录以读取System64就是很小的更改，并且预编译指令旨在处理该更改。

其他人已经很好地解释了这个ridiculus难题……我认为克里斯·霍夫曼在这里做得更好：https：//www.howtogeek.com/326509/whats-the-difference-between-the- Windows中的system32和syswow64文件夹/

我的两个想法：

1. 我们每个人在生活中都会犯愚蠢的短视错误。当微软将他们当时的Win32 DLL目录命名为“ System32”时，这在当时是有意义的……他们只是没有考虑到64位（或128位）版本时的情况。他们的OS后来才开发出来-这样的目录名会引起大量的向后兼容性问题。后见之明总是20到20，所以我不能为这样的错误真正责怪他们（太多）。...但是...当微软后来开发了64位操作系统时，即使有了事后的见解，为什么呢？为什么他们不仅会再次犯完全相同的近视错误，而且会因目的不当而使情况变得更糟这样一个令人误解的名字？！？他们真丢人！！！为什么不至少将目录实际命名为“ SysWin32OnWin64”以避免混淆？？当他们最终生产128位OS时会发生什么……然后将32位，64位和128位DLL放在哪里？！

2. 所有这些逻辑在我看来仍然是完全有缺陷的。在Windows的32位版本上，System32包含32位DLL。在Windows的64位版本上，System32包含64位DLL ...这样开发人员就不必进行代码更改了，对吗？这种逻辑的问题在于，那些开发人员要么正在制作需要64位DLL的64位应用程序，要么正在制作需要32位DLL的32位应用程序...不管是哪种方式，他们是否还搞砸了？我的意思是，如果他们仍在制作32位应用程序，因为它现在可以在64位Windows上运行，那么他们现在需要进行代码更改以查找/引用与它们相同的32位DLL。以前使用过（现在位于SysWOW64中）。或者，如果他们使用的是64位应用程序，则无论如何都需要为新OS重新编写其旧应用程序……因此，无论如何都需要重新编译/重建！！

微软有时会伤害我。