我想知道何时需要在
下放置文件 在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 \ System 32
很混乱的东西。这背后的原因是什么？
答案 0 :(得分：215)
我认为目的是重命名System32，但是有很多应用程序为该路径进行了硬编码，因此删除它是不可行的。
SysWoW64不适用于64位系统的dll，它实际上类似于“Windows64上的Windows”，这意味着你需要在64位Windows上运行32位应用程序。
This article解释了一下：
“Windows x64的目录System32包含64位DLL（原文如此！）。因此，位数为64的本机进程找到他们所期望的”他们的“DLL：在System32文件夹中。第二个目录，SysWOW64，包含32位DLL。文件系统重定向器可以隐藏32位进程的真实System32目录，并以System32的名称显示SysWOW64。“
编辑：如果您正在谈论安装程序，那么您确实 不应该 硬编码系统文件夹的路径。相反，让Windows根据您的安装程序是否在仿真层上运行来为您处理。
答案 1 :(得分：23)
我应该补充一点：你不应该把你的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提供的文件... 不适合任何人使用的文件。人们养成放东西的坏习惯的唯一原因是因为它总是在搜索路径中，并且许多应用程序/模块使用静态链接。 （所以，如果你真的了解它，真正的罪恶是静态链接 - 这是本机代码和托管代码中的罪 - 总是总是动态链接！）
答案 2 :(得分：6)
进入相同的问题并研究了几分钟。
我被教过使用Windows 3.1和DOS，还记得那些日子吗？在我使用Macintosh计算机一段时间之后不久，在购买x64位计算机后开始转向Windows。
这些变化背后的实际原因（有些人会说具有历史意义）是程序员继续工作所必需的。
上面提到了大多数变化：
Program Files vs Program Files (x86)
一开始，16 / 86bit文件被写入'86'英特尔处理器。
System32实际上意味着System64（在64位Windows上）
当开发人员第一次开始使用Windows7时，存在一些兼容性问题，其中存储了其他应用程序。
SysWOW64的确意味着SysWOW32
基本上，用简单的英语来说，它意味着'在64位机器上的Windows上的Windows'。每个文件夹都指示DLL所在的应用程序所在的位置。
以下是两个链接，其中包含您需要的所有基本信息：
希望这可以解决问题！
答案 3 :(得分：5)
System32是Windows历史上放置所有32位DLL的地方，而System是16位DLL。当微软创建64位操作系统时，我所知道的每个人都希望文件驻留在System64下，但微软认为将64位文件放在System32下更有意义。我能找到的唯一理由是，他们希望32位的所有内容都能在64位Windows中运行，而不必更改程序中的任何内容 - 只需重新编译即可完成。他们解决这个问题的方式，即32位应用程序仍然可以运行，就是在Windows64上创建一个名为Windows32的32位Windows子系统。因此，首字母缩写词SysWOW64是为32位子系统的System目录创建的。 Sys是System的缩写，WOW64是Windows32OnWindows64的缩写 由于Windows 16已经与Windows 32隔离，因此不需要Windows 16 On Windows 64等效。在32位子系统中，当程序使用system32目录中的文件时，它们实际上从SysWOW64目录中获取文件。但这个过程是有缺陷的。
这是一个可怕的设计。根据我的经验，我不得不为编写64位应用程序做了很多更改，只需将System32目录更改为读取System64将是一个非常小的更改，并且预编译器指令将用于处理。
答案 4 :(得分：1)
其他人已经很好地解释了这个嘲笑之谜……我想克里斯·霍夫曼在这里做得更好：https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows/
我的两个想法：
我们都在生活中犯了愚蠢的短视错误。当Microsoft将其当时的Win32 DLL目录命名为“ System32”时，这在当时是有意义的……他们只是没有考虑如果/当使用64位（或128位）版本时会发生什么情况。他们的OS后来才开发出来-这样的目录名会引起大量的向后兼容性问题。后见之明总是20到20，所以我不能为这样的错误真正责怪他们（太多）。 ...但是...当微软后来开发了64位操作系统时，即使有了事后的见解，为什么呢？为什么他们不但会再次犯完全相同的近视错误，而且会因目的不当而使情况变得更糟这样一个令人误解的名字？！？他们真丢人！！！为什么不至少将目录实际命名为“ SysWin32OnWin64”以避免混淆？！当他们最终生产128位OS时会发生什么……然后将32位，64位和128位DLL放在哪里？！
所有这些逻辑在我看来仍然是完全错误的。在Windows的32位版本上，System32包含32位DLL。在Windows的64位版本上，System32包含64位DLL ...这样开发人员就不必进行代码更改了，对吗？这种逻辑的问题在于，那些开发人员要么正在制作需要64位DLL的64位应用程序，要么正在制作需要32位DLL的32位应用程序……不管是哪种方式，他们是否还搞砸了？我的意思是，如果他们仍在制作32位应用程序，因为它现在可以在64位Windows上运行，那么他们现在需要进行代码更改以查找/引用与他们相同的32位DLL。以前使用过（现在位于SysWOW64中）。或者，如果他们正在使用64位应用程序，则无论如何他们都需要为新的OS重新编写其旧应用程序...因此，无论如何都需要重新编译/重建！ / p>
微软有时会伤害我。