我有一个在32位Vista系统上运行的cmd文件。
我注意到代码中有对system32驱动程序文件夹的引用。
我想知道这段代码在64位Windows 7系统上是否能够运行。所以我的问题是：64位系统是否包含system32文件夹？
非常感谢任何回复。
4个回答
14
64位Windows操作系统中的System32文件夹实际上包含了64位文件，而在WOW64下运行的32位程序通常会在System32中查找它们可以调用的32位DLL等文件，但它们会发现64位文件。因此，操作系统将所有32位应用程序对System32文件夹的请求重定向到包含32位系统文件的SysWOW64文件夹。
- Rook
3
10所以
system 32 文件夹包含所有的 64位 DLL，而 SysWOW64 文件夹包含所有的 32位 DLL？什么鬼？为什么不是用 System32 来存放 32位 DLL，而使用 System64 存放 64位 DLL 呢？ - Braden Best2@B1KMusic：“本意是重命名System32文件夹，但由于许多应用程序都将该路径硬编码，因此删除它是不可行的。” https://dev59.com/83NA5IYBdhLWcg3wdtr5#950011 - phuclv
@B1KMusic，有没有人知道为什么我在64位Windows上的system32文件夹中包含32位版本的cmd、sfc、dism等，即使我从medicreationtool重新安装了Windows？ - jungle_mole
7
Windows有一项名为WoW 64（Windows-on-Windows 64-bit）的技术，允许32位应用程序（即使是使用C/C++等语言编写的已编译应用程序）在64位Windows上运行。
除了System32文件夹外，64位Windows安装还有一个名为SysWow64的文件夹，其中包含您在System32中找到的文件的32位版本。
需要说明的是，在从32位进程运行时，对System32的引用会被重定向（除非进程禁用此重定向，这是可能的）。因此，如果您有一个引用System32的.CMD文件，它实际上将从SysWow64目录中读取。
- user2048753
2
非常感谢，我想我明白了。你如何知道你的应用程序是32位的？ - hmmlee
这是一个命令行脚本（.CMD文件）吗？这是我从你的帖子中得到的印象。如果是，它将在任何地方执行，我不确定你所说的“对System32的引用”是什么意思，但我想它直接访问那里的文件。如果这是一个已编译的应用程序，并且您安装了Visual C ++，则可以使用LINK / DUMP / HEADERS <file> .exe，在FILE HEADER VALUES的最顶部，您将看到带有括号名称的'machine'。如果是（i386），则为32位。我忘记了x64列出了什么，但它可能是（x64）或（amd64）。 - user2048753
2
“System32”是一个包含重要操作系统文件的文件夹的名称。
早期版本的64位Windows XP只能运行64位应用程序。这是有道理的：
- 在16位Windows上运行16位应用程序 - 在32位Windows上运行32位应用程序 - 在64位Windows上运行64位应用程序
早期的64位Windows XP也是64位的，只支持运行64位应用程序。
由于所有文件夹名称保持不变，因此您可以将应用程序简单地重新编译为64位（而无需更改任何其他内容 - 包括意外硬编码的路径），它就会正常工作。
在64位Windows上模拟32位操作系统
很快就显然，只能在64位Windows上运行64位应用程序，将阻止一些人升级到64位Windows。因此，创建了{{link1：一个仿真层，允许您在64位操作系统上运行32位应用程序。}}
它被称为WOW64：
这一切都是正确的；如果你将你的32位应用程序重新编译为64位，那么一切都可以正常工作。所有这些位置仍然是正确的。
在64位世界中的32位应用程序
但现在，由于我们要尽力容纳非64位应用程序，我们必须找到一些地方让它们保留旧的32位操作系统文件、存储32位数据以及拥有32位程序和32位共享组件：
问题在于：
如果一个32位程序认为自己正在运行旧的32位操作系统，并请求32位位置，则需要给出“真实”位置：
如果你不想让你的32位应用程序受到所有这些仿真和转换的影响，那么解决方案是显而易见的：
早期版本的64位Windows XP只能运行64位应用程序。这是有道理的：
- 在16位Windows上运行16位应用程序 - 在32位Windows上运行32位应用程序 - 在64位Windows上运行64位应用程序
早期的64位Windows XP也是64位的，只支持运行64位应用程序。
由于所有文件夹名称保持不变，因此您可以将应用程序简单地重新编译为64位（而无需更改任何其他内容 - 包括意外硬编码的路径），它就会正常工作。
在64位Windows上模拟32位操作系统
很快就显然，只能在64位Windows上运行64位应用程序，将阻止一些人升级到64位Windows。因此，创建了{{link1：一个仿真层，允许您在64位操作系统上运行32位应用程序。}}
它被称为WOW64：
Windows on Windows64：
- 这个仿真层模拟x86架构，虚拟CPU、文件系统、注册表、环境变量、系统信息函数等等。
- 如果32位程序试图查看系统，它将看到一个32位系统。
- 例如，如果程序调用GetSystemInfo函数查看正在运行的处理器是什么，它将被告知它正在运行在一个32位处理器上，具有32位地址空间，在一个有32位天空和32位树中有32位鸟的世界中。
- 这就是仿真的目的：通过模拟32位执行环境来使32位程序满意。
问题在于这些32位应用程序应该把它们的32位文件存储在哪里，并配置它们的32位DLL的位置，并加载32位操作系统支持文件？
我们已经知道本地应用程序存储它们的东西的位置了。
| Native Application |
|---------------------|
| C:\Windows\System32 |
| C:\Program Files |
| HKCU\Software |
这一切都是正确的；如果你将你的32位应用程序重新编译为64位，那么一切都可以正常工作。所有这些位置仍然是正确的。
在64位世界中的32位应用程序
但现在，由于我们要尽力容纳非64位应用程序，我们必须找到一些地方让它们保留旧的32位操作系统文件、存储32位数据以及拥有32位程序和32位共享组件：
| Native Application | Emulated 32-bit |
|---------------------|---------------------------|
| C:\Windows\System32 | C:\Windows\SysWOW64 |
| C:\Program Files | C:\Program Files (x86) |
| HKCU\Software | HKCU\Software\Wow6432Node |
问题在于：
- 如果一个64位程序请求
C:\Windows\System32，它必须得到64位文件 - 如果一个32位程序请求
C:\Windows\System32，它必须得到32位文件
如果一个32位程序认为自己正在运行旧的32位操作系统，并请求32位位置，则需要给出“真实”位置：
| Native Application | Emulated 32-bit asks for | Is actually given |
|---------------------|---------------------------|---------------------------|
| C:\Windows\System32 | C:\Windows\System32 | C:\Windows\SysWOW64 |
| C:\Program Files | C:\Program Files | C:\Program Files (x86) |
| HKCU\Software | HKCU\Software | HKCU\Software\Wow6432Node |
如果你不想让你的32位应用程序受到所有这些仿真和转换的影响，那么解决方案是显而易见的：
- 为64位操作系统创建一个64位应用程序
- Ian Boyd
1
一个超过8年历史的问题终于有了答案！我本来是来关闭它的，但最后却点了个赞。这真是罕见...讲解得非常好，易于理解。 - Stephan
0
Windows 7 64位有一个System32文件夹。
然而，你的文件是否仍能运行是一个更复杂的问题。它可能会，完全取决于它所依赖的内容；如果它以错误的方式依赖驱动程序，则会失败，因为32位驱动程序在64位系统上无法工作。
- me_and
2
非常感谢您抽出时间回复..但是当您说错误地依赖于驱动程序时，您是什么意思？ - hmmlee
不了解具体情况，我无法做出判断！如果您的代码依赖于某个特定驱动程序的技术细节，那么在Win64下该驱动程序可能会有所不同，从而导致失败。您能发布相关代码吗？ - me_and
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接