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

我知道在Windows的64位版本上，“ Program Files”文件夹用于64位程序，而“ Program Files（x86）”文件夹用于32位程序，但是为什么还要这样做？

“必要”不是指“微软为什么不能做出其他任何设计决定？” 因为他们当然可以拥有。相反，我的意思是，“为什么考虑到当前64位Windows的设计，为什么32位程序必须具有与64位程序分开的顶层文件夹？” 换句话说，“如果我以某种方式避免了重定向机制而将所有内容都强制安装到真正的地方，将会出C:\Program Files\什么问题？”

在“超级用户”和其他地方，有很多问题断言“一个是针对32位程序的，一个是针对64位程序的”，但我找不到能给出原因的。根据我的经验，是否将32位程序安装在正确的位置似乎并不重要。

Windows是否会以某种方式与“程序文件（x86）”用尽的程序呈现不同的外观？是否有说明完全显示了“程序文件（x86）”中安装的程序而不是“程序文件”的不同之处？我认为，在没有正当技术理由的情况下，微软不太可能推出新文件夹。

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

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

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

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

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

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

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

因此，让我们分解一下！

1. 文件夹很棒！

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

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

2. 分离数据和逻辑很棒！

   在编程中经常发现的一种范例是将数据与逻辑分离。你想那一部分知道如何做一些事情，你想另一部分，你可以做什么用。

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

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

   逻辑

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

   数据

   • %PROGRAMDATA%
   • %HOMEDRIVE%%HOMEPATH%

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

3. 安装程序不是魔术

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

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

   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来检索正确的路径）。
   一切都会自动找到它，并且安装的每个应用程序的模式都相同。

4. 一致性很有意义

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

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

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

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

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

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

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

32位应用程序将所有这些请求重定向到32位应用程序中，以避免应用程序崩溃。

我们需要一些固定的文件夹名称来构建这样的系统。如果没有支持此重定向的文件夹结构，那么您将如何使其工作？

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

现在我们有了哲学...

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

最有可能的是什么（只要其他应用程序不依赖于该应用程序的固定位置）。

的WOW64机构钩入CreateProcess和将执行更复杂的（不是检查可执行文件的文件夹的名称更复杂的）检查可执行图像上以确定它是否是32或64位。

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

• 如果我把会发生什么，这两个柴油机和气体进入我的车？
• 如果我尝试在同一条线上同时使用交流电和直流电，会发生什么情况？
• 如果我继续会发生什么，都我的猫，我的鱼在鱼缸一样？

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

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位应用程序的方式。

当你有或没有管理员权限运行一个程序，它会影响它是如何运行的，但位置应不影响它（虽然也有像一些司机例如位置依赖的一些例子）。

（我使用的是另一台计算机，因此我不能依靠浏览器的历史记录来回溯我的步骤，但是前几天，在回答此SU问题时，我最终遇到了这个SO问题，导致我进入Google PROCESSOR_ARCHITEW6432，从而导致了该SO问题，此Microsoft博客文章。）

一路上的某个地方，我读了一个StackOverflow帖子，内容关于环境变量如何%processor_architecutre% 根据运行命令提示符的位置给出不同的结果（我将尝试查找确切的引用）。

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

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

FreePascal允许您安装DOS和Windows版本，它们位于同一文件夹中：%programfiles%\FreePascal。它通过保持可执行文件（管理不同的架构.exe，.sys，.dll，.ovr在不同的文件夹等）和共享的资源文件如图片，源文件等）没有技术理由，这可能不是也可以支持32位和完成程序的64位版本。就像David所说的那样，如果程序员保持独立（即使用变量使它看起来像只有一组文件，等等）对程序员来说会更容易。

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

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

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位程序，并且不会发生任何事情，程序将运行相同的程序。

维基说：

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

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

这样可以避免冲突，使开发人员在不花太多时间就将编译模式更改为64位的情况下不知所措，并避免了希望用户能够安装其32位和64位版本的开发人员的大量工作。软件同时进行。

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

在“程序文件（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在运行时将确定应用程序是32位还是64位，并自动使用适当的DLL和注册表部分。

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

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

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

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

如@OliverSalzburg所指出的那样，这可能很有用– 如果您希望同时安装64位和32位网络浏览器（例如），因为某些插件和附加组件可能仅适用于以下其中一种：他们俩。

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

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

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

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

通常指向C:\Program Files。

但是，如果安装程序是32位应用程序，则注册表重定向将导致重新注册密钥

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

而是通常指向C:\Program Files (x86)。

为什么使用这些特定的文件夹名称，只能由做出此选择的人员回答。如果需要，您始终可以更改默认文件夹的名称。

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

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

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

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

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

当然，这阻止了我同时安装一个应用程序的两个版本（32位和64位），但这对我来说不是问题。

每当您启动程序时，总是会先C:\Windows\System32\ntdll.dll执行DLL 。此DLL确定您的程序是32位还是64位应用程序。取决于您已被重定向到WoW64已经在多个答案中提到的内容。