为什么64位Windows需要一个单独的“程序文件（x86）”文件夹？

#1 楼

简短的答案：为确保旧的32位应用程序继续按照以前的方式运行，而不会在会造成永久性混乱的64位应用程序上施加难看的规则。

这是没有必要的。它比其他可能的解决方案更加方便，例如要求每个应用程序创建自己的方式以将32位DLL和可执行文件与64位DLL和可执行文件分开。

主要原因是要使32-甚至不知道64位系统的位应用程序也可以正常工作，即使将64位DLL安装在它们看上去可能会出现的位置。 32位应用程序将无法加载64位DLL，因此需要一种方法来确保32位应用程序（可能早于64位系统，因此不了解64位文件）甚至不存在）都找不到64位DLL，尝试加载它，失败，然后生成错误消息。

最简单的解决方案是始终使用单独的目录。确实，唯一的选择是要求每个64位应用程序“隐藏”其可执行文件到32位应用程序看不到的位置，例如该应用程序中的bin64目录。但这将在64位系统上施加永久性的丑陋，以仅支持旧版应用程序。

#2 楼

它允许您安装应用程序的32位和64位版本，而不会覆盖自身。


第二天看了这个答案并发表评论后，我意识到可能会有重大的疏忽在我的回答中。我错误地假定了一个编程背景，当我在评论中谈论您时，我并不是指用户，而是程序员。

我不在Microsoft工作，也不知道要做什么。这些文件夹背后的真正原因是，但是我认为拥有这些文件夹的原因是如此明显，以至于我对此毫无疑问。

所以让我们分解一下吧！



文件夹真棒！

让我们达成共识。文件夹很棒！我们不需要它们，我们有足够的可能的文件名来将每个文件都放在硬盘驱动器的根目录上，那么为什么根本没有文件夹呢？

好，它们可以帮助我们订购东西。而且订购东西很棒。它有助于我们更轻松地处理事物。在需要结构的机器上使用时特别有用。


分离数据和逻辑非常好！

在编程中经常发现的一种范式是分离来自逻辑的数据。您需要一个知道如何做某事的部分，而您想要另一个可以做某事的部分。

这也可以在文件系统中找到。

我们有用于贵重物品（数据）的应用程序（逻辑）和文件夹：

逻辑


%WINDIR%
%PROGRAMFILES%
%PROGRAMFILES(x86)%

数据


%PROGRAMDATA%
%HOMEDRIVE%%HOMEPATH%

因此，文件夹看起来很棒，将程序放在自己的小文件夹中很有意义。但是为什么要有2个？为什么不让安装程序处理该问题并将所有内容放入一个Programs文件夹中？


安装程序不是魔术

今天，我们经常使用小程序来安装我们的较大的程序。我们称这些小程序安装程序。

安装程序不是魔术。它们必须由程序员编写，并且像其他任何应用程序一样都是应用程序（可能存在错误）。因此，让我们来看一个假想的程序员在不使用当前系统的情况下必须面对的情况：

1 Program Files文件夹

开发人员维护2个安装程序。一种用于他的应用程序的32位版本，另一种用于他的应用程序的64位版本。 32位安装程序将写入C:\Program Files\App\，而64位安装程序将写入C:\Program Files\App\sixtyfour\。

2个Program Files文件夹

开发人员维护1个安装程序。安装程序将始终写入%PROGRAMFILES%并依赖于操作系统来相应地扩展路径（在这些情况下，您实际上不使用环境变量，而应将SHGetKnownFolderPath与FOLDERID_ProgramFiles一起使用以检索正确的路径）。
所有内容会自动发现它的位置，并且模式与您安装的每个应用程序都相同。


一致性是有意义的

当您学到一些东西时，通常意味着观察到的行为是一致的。否则，实际上没有什么可观察和学习的。

我们的小文件系统也是如此。始终将相同的内容放入相同的文件夹是有意义的。这样，我们将在寻找所需内容时知道在哪里寻找。

用于32/64应用程序区分的系统进一步推动了这一目标。应用程序分为两个位置，以避免名称，二进制加载行为和安全性（在某种程度上）上的冲突。


我还是不明白。这似乎没用

您永远都不要忘记一件事。人们真是愚蠢。这包括用户，超级用户，尤其是程序员。

这就是为什么我们需要诸如文件系统重定向之类的东西才能使我们的系统可用。

程序员只是去那里尝试加载C:\Windows\system32\awesome.dll，而不关心它们是在32位还是64位系统上运行。他们将尝试加载64位DLL并崩溃。一些程序员想使用一些Office DLL，没问题，他们知道在哪里可以找到它！ C:\Program Files\Microsoft\Office.0\wizards.dll ...并再次崩溃！

32bit应用程序的所有这些请求都被重定向到32bit对应对象，以避免应用程序崩溃。

我们需要一些固定的文件夹名称来构建一个系统。如果没有支持这种重定向的文件夹结构，那么如何使它起作用？

好，现在我明白了。但是为什么不使用C:\Program Files\x86\呢？

现在我们开始了解哲学了。

如果我以某种方式避免了重定向机制而将所有内容都强制安装到真正的C:\Program Files\？

几乎没有任何内容（只要其他应用程序不依赖于该应用程序的固定位置）。

WOW64机制挂接到CreateProcess上，它将对可执行映像进行更复杂的检查（比检查可执行文件的文件夹名称更复杂），以确定它是32位还是64位。

是的，但是我的意思是，所有应用程序都一样！


如果我将柴油和汽油同时放入车中会发生什么？
尝试在同一条线上同时使用交流电和直流电吗？
如果我把猫和鱼都放在同一个水族箱中会发生什么？

有些问题不需要答案。它不是要做的，不要做。这里没有任何收获。此类更改可能引起的问题的数量始终大于某人在此中可能看到的任何好处。

#3 楼

TL; DR：

总而言之，不，没有必要；他们本可以使用一个文件夹，但是不，Windows的外观与从一个位置或另一个位置运行的程序没有不同。


好吧，每个人似乎都在表达他们的意见。这样，我就扔2美分。其他人已经对Microsoft为什么选择为32位和64位版本的程序创建单独的顶级文件夹的原因进行了猜测，因此我将保留这一部分（最好的原因是David解释说，方便程序员）。当然，即使那样，它仍然没有完全解决直接的问题，为什么这甚至是必要的？答案大概是：没有。

相反，我将解决主体的主体问题。问题


Windows是否会以某种方式与用完“程序文件（x86）”的程序呈现不同的外观？


不是，但是程序的位置可能会影响行为，但不会影响您的想法。

运行程序时，Windows会设置运行该程序的环境（我的意思是在内存，寻址等，而不仅仅是环境变量）。此环境取决于可执行文件的内容（内部的32位和64位程序不同）。在64位系统上运行32位程序时，该程序将在模拟32位环境的32位子系统中运行。它称为WoW64（WoW64表示Windows在64位系统上为Windows），类似于使用NTVDM在XP中运行16位应用程序的方式。

在运行带有或不带有admin的程序时特权，它会影响它的运行方式，但位置不会影响它（尽管有一些位置依赖的示例，例如某些驱动程序）。

（我使用的是另一台计算机，所以我不能依靠浏览器的历史记录来回溯我的步骤，但是前几天，在回答此SU问题时，我遇到了这个SO问题，导致我遇到Google PROCESSOR_ARCHITEW6432，从而导致了该SO问题，此Microsoft博客文章。）在整个过程中的某个地方，我读了一个StackOverflow文章，内容关于环境变量%processor_architecutre%如何根据从何处运行命令提示符而给出不同的结果（我将尝试查找确切的引用）。

答案是由于运行命令提示符的32位版本还是64位版本（例如，从System32\或SysWoW64\）引起的。换句话说，尽管位置似乎影响程序的行为，但这仅是因为程序的版本不同，而不是因为Windows以特殊方式对待文件夹。

这很有意义，因为可执行文件的内容决定了它是32位还是64位，因此您可以将同一程序的32位和64位副本（例如foobar32.exe和foobar64.exe）放置在同一文件夹中，并在执行它们时将它们放入同一文件夹中，它们将被正确加载（64位版本将在本地运行，而32位版本将在WoW64仿真层中运行）。

FreePascal允许您同时安装DOS和Windows版本。它们位于相同的文件夹中：%programfiles%\FreePascal。它通过将可执行文件（.exe，.sys，.dll，.ovr等）保存在单独的文件夹中并共享资源文件（例如图片，源文件等）来管理不同的体系结构。没有技术原因不能做到这一点适用于32位和64位版本的程序。就像David所说的那样，如果程序员保持分开（即使用变量使它看起来像只有一组文件等），那么对于程序员来说更容易。

#4 楼

另一个原因是，大多数程序过去都使用诸如％PROGRAMFILES％之类的环境变量来指向其程序的安装位置。对于64位程序，它将转到正常位置。对于32位程序，它将重定向到新的Program Files (x86)文件夹。

尽管，至少对于Visual Studio中的新.Net东西，它们现在具有App.Local变量，从而消除了全部需求为此。

#5 楼

Microsoft从32位到64位过渡的解决方案是为大多数32位应用程序添加旧版支持。换句话说，大多数32位应用程序将在64位操作环境中运行。请记住，在64位体系结构上运行的其他操作系统完全不能加载或运行32位应用程序。

为了帮助简化过渡过程，Microsoft指定所有32位应用程序应（默认情况下）被加载到Program Files（x86）文件夹中，而不是与常规Program Files文件夹中的真正的64位应用程序混在一起。


源

“如果我以某种方式避免了重定向机制，而将所有内容都强制安装到真正的C：\ Program Files \，那会出什么问题？”

没事。这两个程序目录仅用于组织，或者用于将具有32位和64位两个版本的程序分开，例如Internet Explorer。但是您可以在“程序文件”中安装32位程序，并在“程序文件x86”中安装64位程序，但不会发生任何事情，程序将运行相同的程序。

Wiki说：


某些应用程序安装程序会拒绝安装路径位置中的空格。对于32位系统，Program Files文件夹的简称为Progra〜1。对于64位系统，64位Program Files文件夹的简称为Progra〜1（与32位系统相同）。而32位Program Files（x86）文件夹的简称现在为Progra〜2。

#6 楼

原因是使开发人员更容易将程序升级到64位。他们无需编写任何自定义代码即可在以32位模式进行编译时在一个目录中检查程序，而在以64位模式进行编译时则在另一目录中检查程序。他们只检查C:\Program Files，然后在32位模式下运行时，该值会自动由64位Windows更改为C:\Program Files (x86)。同样，注册表项在32位和64位程序之间是隔离的。

这样可以避免冲突，使开发人员无需过多考虑就可以将编译模式更改为64位，从而避免冲突。对于希望用户能够同时安装其32位和64位版本的软件的开发人员而言，工作量很大。


但是为什么任何程序都希望同时允许这两个版本同时安装？一个示例：Photoshop和IE具有本机.dll的扩展名。您不能在同一过程中混合使用32位和64位代码，因此32位版本的附加组件不能与64位版本一起使用，反之亦然。因此，Photoshop / IE必须允许同时安装两个版本，否则可能会破坏其现有附加组件的庞大基础。

#7 楼

在“程序文件（x86）”上运行的程序使用WOW64子系统（Windows 64位上的Windows 32位是旨在在x64体系结构系统上运行x32应用程序的一组驱动程序和API）：


WoW64子系统包括一个轻量级的兼容性层，该层在所有64位版本的Windows上都具有相似的接口。它旨在
创建一个32位环境，该环境提供在64位系统上运行未修改的32位Windows应用程序所需的接口。
从技术上讲，WoW64使用三个动态的-链接库
（DLL）：


Wow64.dll，Windows NT内核的核心接口，可在32位和64位调用之间进行转换，包括指针和调用
堆栈操作
Wow64win.dll，它为32位应用程序提供了适当的入口点。
Wow64cpu.dll，它负责将处理器从32位模式切换到64位模式




64位系统需要“模拟” 32位应用程序，这就是Windows需要“隔离”两个Program Files文件夹的原因。

评论

---

但是为什么必须将其放在不同的文件夹中？ Windows已经完全能够通过查看PE标头来确定可执行文件的体系结构。为什么在加载可执行文件时无法加载适当的环境？

– Synetech
2012年6月27日17:40

---

我认为这是Microsoft的一个选择，可以轻松地向用户显示他们在打开程序时需要两个程序版本的体系结构。我的意思是，如果没有这两个文件夹，并且对用户是透明的（如果它自动切换），他们甚至不知道运行32位还是64位应用程序，甚至他们也不知道要打开哪个程序如果在64位上运行。

–圣地亚哥
2012年6月27日17:48

---

IE的64位版本以其糟糕而著称。

–塞缪尔·埃德温·沃德（Samuel Edwin Ward）
2012年6月27日18:29

---

MS建议使用office32，除非您使用的数据集足够大以超过内存限制。我认为需要重新编译二进制插件才能与office64协同工作；再加上在正常使用情况下不提供任何好处，都是决定的依据。

–丹在火光中摆弄
2012年6月27日18:36

---

我想您会发现，显式安装到Program Files（x86）文件夹中的64位程序可以正常正常运行（在大多数情况下，反之亦然）。 Windows不会使用文件夹位置来确定如何处理可执行文件。

–哈里·约翰斯顿（Harry Johnston）
2012年6月29日在2:38

---

#8 楼

有趣的是，这里和整个互联网上的答案相差很大。为这个重要问题找到准确的答案一直是一个挑战。互联网上似乎存在大量虚假信息，导致混乱。

我进行了大量研究，得出了以下结论，我认为这是正确的：


存储应用程序的位置没有区别。在运行时，Windows将确定应用程序是32位还是64位，并自动使用相应的DLL和注册表部分。

这是自动发生的，并且与应用程序的存储位置无关。具有单独的32位和64位文件夹没有速度，可靠性或其他功能优势。

将默认默认分为两个文件夹（“程序文件”和“程序文件”）的唯一原因（x86）'）是如果同一程序有两个版本（32位和64位版本），它提供了一种简单的方法来使重叠文件分开。即使在这种情况下，只要所有文件名都是唯一的，它们实际上就可以存在于同一个文件夹中而不会产生任何后果。

以上结论有一个警告，那就是糟糕的一个。编码的应用程序。如果应用程序有任何硬编码到其中的路径，它将仅使用该路径。通常，绝对不应将路径硬编码到应用程序中，但程序员有时会犯此错误。在这种情况下，程序将使用硬编码路径。应用程序的安装目录不会影响它实际查找文件的位置。

#9 楼

不必分开文件夹，就可以将需要WoW64的本机64位应用程序和代码分开。

这很有用–正如@OliverSalzburg指出的–如果您希望同时安装两个文件夹， Web浏览器的64位和32位（例如），因为某些插件和加载项可能仅适用于这两种浏览器之一。

必须分开文件夹才能使这种分离自动进行使用注册表重定向之类的技术。

假定安装程序通过使用RegQueryValueEx读取注册表来尝试确定程序文件文件夹。

无论如何，它尝试读取注册表项

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

通常指向C:\Program Files。

但是，如果安装程序是32位应用程序，则注册表重定向将导致改为读取regitry键

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

，通常指向C:\Program Files (x86)。为什么要使用这些特定的文件夹名称可以做出选择的人们会回答。如果愿意，您可以随时更改默认文件夹的名称。


Windows是否会以某种方式对用完“程序文件（x86）”的程序呈现不同的外观？


我对此表示怀疑。大多数安装程序允许您选择自定义安装文件夹，因此在哪里安装程序并不重要。

#10 楼

我不能相信这里的困惑。首先，我是一名专职开发人员。

MS这样做是为了解决旧版32位应用程序和新版64位应用程序都使用DLL的情况。位应用程序。无法更改旧方法（System32，程序文件等），因为这会破坏无法重新编译的旧程序。

因此，MS创建了一个文件夹来存储64位特定的程序，程序集和库，以便新程序可以链接到适当的库，而旧程序将继续正常运行。

目前，.Net DLL可与同一台计算机上的其他版本共存。例如，您可以具有Library.1.0.1，Library.1.0.2，Library 1.1.0等。这仅适用于特定的位大小（32或64）。如果不使用单独的文件夹，则每个程序集都需要具有32位和64位版本。这将严重地弄乱已经包含同一程序集多个版本的目录。

这都是开发人员的工作。作为用户，只有在Windows 7 64上使用32位程序时，才需要处理它。我更喜欢能够在32位版本中运行32位版本和相同应用程序的能力。当我需要在64位上进行编译的32位应用程序上时，我要做的就是告诉编译器这样做。 Dll名称和其他所有内容保持不变。

Windows 95/98中不存在此名称的原因是那些系统模拟了32位运行时；它不是真正的32位操作系统。它使用名为“ thunking”的东西伪造了32位执行程序。

这是一个很好的定义：http://searchwinit.techtarget.com/definition/thunk

#11 楼

完全没有必要。例如，在工作的计算机上，我将每个应用程序都安装在文件夹C:\MyPrograms\中，以使其与IT部门安装的应用程序分开。

当然，这使我无法同时安装这两个版本（32位和64位） ），但就我而言，这没有问题。

无论何时启动程序，总会首先执行DLL C:\Windows\System32\ntdll.dll。该DLL确定您的程序是32位还是64位应用程序。取决于您，您将被重定向到已经在几个答案中提到的WoW64。