我想知道我们什么时候需要在下面放置一个文件
C:\Windows\System32 或 C:\Windows\SysWOW64，在 64 位 Windows 系统上。
我有两个 DLL，一个用于 32 位，一个用于 64 位。
从逻辑上讲，我认为我会将 32 位 DLL 放在 C:\Windows\System32 下，将 64 位 DLL 放在 C:\Windows\SysWOW64 下。
令我惊讶的是，情况恰恰相反！32位 DLL进入C:\Windows\SysWOW 64，64位 DLL 进入 C:\Windows\System 32。
很混乱的东西。这背后的原因是什么？
我相信其目的是重命名 System32，但是为该路径硬编码的应用程序太多，因此删除它是不可行的。
SysWoW64 不是为 64 位系统的 dll 设计的，它实际上类似于“Windows on Windows64”，这意味着您需要在 64 位 Windows 上运行 32 位应用程序的位。
这篇文章稍微解释一下：
“Windows x64 有一个目录 System32，其中包含 64 位 DLL（原文如此！）。因此，位数为 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% 或 %ProgramFiles(x86)% 来查找 Program Files 的位置...。您不要假设它是 c:\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
本质上，用简单的英语来说，它的意思是'Windows on Windows in a 64-bit machine'。每个文件夹都指示它们希望使用它们的应用程序的 DLL 所在的位置。
这里有两个链接，其中包含您需要的所有基本信息：
希望这可以解决问题！
System32 是 Windows 历史上放置所有 32 位 DLL 的位置，而 System 用于放置 16 位 DLL。当微软创建 64 位操作系统时，我认识的每个人都希望文件驻留在 System64 下，但微软认为将 64 位文件放在 System32 下更有意义。我能找到的唯一理由是，他们希望 32 位的所有东西都可以在 64 位 Windows 中工作，而无需更改程序中的任何内容——只需重新编译，就可以了。他们解决这个问题的方法是在 Windows64 上创建一个名为 Windows32 的 32 位 Windows 子系统，以便 32 位应用程序仍然可以运行。因此，为 32 位子系统的系统目录创建了首字母缩略词 SysWOW64。Sys 是 System 的缩写，WOW64 是 Windows32OnWindows64 的缩写。
由于 Windows 16 已经与 Windows 32 隔离，因此不需要 Windows 16 On Windows 64 等价物。在 32 位子系统中，当程序使用 system32 目录中的文件时，它们实际上是从 SysWOW64 目录中获取文件。但是这个过程是有缺陷的。
这是一个可怕的设计。而且根据我的经验，我必须为编写 64 位应用程序做更多的更改，仅仅将 System32 目录更改为读取 System64 将是一个非常小的更改，并且是预编译器指令旨在处理的更改。
其他人已经很好地解释了这个可笑的难题......我认为克里斯霍夫曼在这里做得更好： https ://www.howtogeek.com/326509/whats-the-difference-between-the- system32-and-syswow64-folders-in-windows/
我的两个想法：
我们在生活中都会犯愚蠢的短视错误。当微软将他们（当时）的 Win32 DLL 目录命名为“System32”时，这在当时是有道理的......他们只是没有考虑到如果/当 64 位（或 128 位）版本会发生什么他们的操作系统是后来开发的——这样的目录名称会导致大量的向后兼容性问题。事后诸葛亮总是 20-20，所以我不能真的责怪他们（太多）这样的错误。......但是......当微软后来开发他们的 64 位操作系统时，即使是事后诸葛亮，为什么哦，为什么他们不仅会再次犯同样的短视错误，而且故意让情况变得更糟这是一个误导性的名字？！？他们真丢人！！！为什么不至少将目录命名为“SysWin32OnWin64”以避免混淆？！? 当他们最终生产出 128 位操作系统时会发生什么……那么他们将把 32 位、64 位和 128 位 DLL 放在哪里？！？
所有这些逻辑在我看来仍然完全有缺陷。在 32 位版本的 Windows 上，System32 包含 32 位 DLL；在 64 位版本的 Windows 上，System32 包含 64 位 DLL……这样开发人员就不必更改代码，对吗？这种逻辑的问题在于，这些开发人员要么现在正在制作需要 64 位 DLL 的 64 位应用程序，要么正在制作需要 32 位 DLL 的 32 位应用程序……不管怎样，他们不是还是搞砸了吗？我的意思是，如果他们仍在制作 32 位应用程序，为了让它现在在 64 位 Windows 上运行，他们现在需要更改代码以查找/引用与他们相同的 ol' 32 位 DLL以前使用过（现在位于 SysWOW64 中）。或者，如果他们正在开发 64 位应用程序，他们无论如何都需要为新操作系统重新编写他们的旧应用程序......所以无论如何都需要重新编译/重建！
微软有时只是伤害了我。