windows中安装程序的原理是什么？
IMO PE 可执行文件不能在所有平台上运行。
我猜测安装程序会打包各种 CPU 架构的可执行文件，并在进行一些检测工作后选择正确的一个。
但这是像微软这样的大公司发布产品的方式吗？
IMO a PE executable can't run on all platforms.
I'm guessing that the installer packs executables for various CPU architectures, and chooses the right one after some detecting work.
But is this how major companies like MS releases their products?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Microsoft 仅发布两种桌面 CPU：x86 和 x86-64。他们通常为每个使用单独的可执行文件。例如，vcredist_x86.exe (x86) 和 vcredist_x64.exe (x86-64)。
但是，在某些情况下，他们确实使用组合安装程序，例如 dotNetFx40_Full_x86_x64.exe。
Microsoft only releases for two desktop CPU's, x86 and x86-64. They generally use separate executables for each. For example, vcredist_x86.exe (x86) and vcredist_x64.exe (x86-64).
However, they do use combined installers in some cases, such as dotNetFx40_Full_x86_x64.exe.
这里似乎有两种思想流派：
这是最简单的方法，因为您无需在安装程序中执行任何特殊操作。许多 Microsoft 实用程序（特别是所有调试工具）都包含在单独的 x86/amd64/ia64 包中；不过，我不确定他们的零售产品。
这里您有一个单一的 32 位安装程序，可以在所有当前支持的 Windows 平台上运行；安装程序包含每个平台的二进制文件。在安装程序中，您可以根据运行的平台放置适当的二进制文件。我建议不要这样做，因为它需要很多“魔法”（自定义代码、黑客等），而且还会使您的安装程序变得臃肿。
我们目前使用第二种方法来分发我们的产品，但事实证明它非常令人头痛，因此我们将来将改用第一种方法。第一种方法的唯一缺点是您要求客户使用正确的安装程序，尽管您可以将其包装在一个简单的 32 位 shell 中以启动适当的安装程序。
It seems like there are two schools of thought here:
This is the most straightforward approach as you don't have to do anything special in your installer. Many of Microsoft's utilities (in particular all of the debugging tools) come in separate x86/amd64/ia64 packages; I'm not sure about their retail products, though.
Here you have a single monolithic 32-bit installer that will run on all currently supported Windows platforms; the installer contains the binaries for each platform. In the installer you lay down the appropriate binaries depending on what platform you are running on. I would recommend against this as it requires a lot of "magic" (custom code, hacks, etc) and it also bloats your installer.
We currently distribute our product using the second method, but it has proven to be quite a headache so we're going to be changing over to the first method in the future. The only downside to the first method is that you require the customer to use the proper installer, though you could wrap this in a simple 32-bit shell that launches the appropriate installer.
这实际上是一个相当复杂的讨论，涉及组件的位数及其依赖项，并且没有任何一种尺寸适合部署人员方法。一些产品是本机/非托管的（不是 .NET ），针对 x86 编译并在 x86 和 x64 上作为 x86 包分发。有些是纯托管 (.NET) 应用程序，它们打包为 x86，但实际上如果可能的话将作为 x64 运行。有些是具有非托管依赖项的托管应用程序，可能需要采用混合方法，例如将 x86 DLL 安装到 32 位计算机上的 WinSXS，将 x64 DLL 安装到 64 位计算机上的 WinSXS。其他人没有直接的依赖关系，但可能需要注册为其他应用程序（例如 Office 或 Internet Explorer）的插件/插件/扩展。
有些软件包作为不同的安装程序分发，有些采用混合方法，有些将分成通过引导程序包装的多个软件包。有些会尝试通过后台网络下载来隐藏膨胀，有些会预先将其全部提供给您以允许离线安装。
答案是：视情况而定。
This is actually a fairly complicated discussion involving the bitness of your components and their dependencies and there isn't any 1 size fits all to the deploymen approach. Some products are native / unmanaged ( not .NET ), compiled for x86 and distribute as an x86 package on both x86 and x64. Some will be be purely managed ( .NET ) applications that are packaged as x86 but in reality will run as x64 if possible. Some will be managed apps that have unmanaged dependencies and possibly need to do a hybrid approach such as installing x86 DLL's to the WinSXS on 32bit machines and x64 DLL's to the WinSXS on 64bit machines. Others have no direct dependencies per say but may need to register as addins / plugins / extensions to other applications such as Office or Internet Explorer.
Some packages distribute as distinct installers, some do a hybrid approach and some will split out into multiple packages wrapped via a bootstrapper. Some will try to hide the bloat via background web downloads and some will give it all to you up front to allow for offline installs.
The answer very much is: It Depends.