为什么“胖二进制文件”没有更广泛地用于跨平台应用程序？

据我所知，所谓的“胖二进制文件”（包含用于多个系统的机器代码的可执行文件）仅在Apple PC上真正使用过，甚至在那里似乎它们仅使用它们是因为它们需要从PowerPC到x86。

如今，许多软件都是跨平台的，似乎制作单个胖二进制文件比跟踪操作系统和体系结构的每种组合的十几个左右不同的下载要简单得多，更不用说以某种方式传达给客户他们想要哪一个。

关于这种方法为何从未流行的原因，我可以提出很多猜测，例如：

• 缺乏交叉编译工具使多操作系统二进制文件不可行
• 无论如何，您都需要在每个操作系统上测试代码，因此您已经必须拥有可以针对每个操作系统进行本地编译的系统
• 显然，32位程序已经可以在64位计算机上“正常工作”
• 动态链接在每个OS上的工作方式都不同，因此即使“胖应用程序”可以运行“胖库”也可能不起作用

但是由于我一直在使用一个库或框架来向我隐藏所有这些特定于操作系统和特定于体系结构的详细信息，所以我不知道这些内容到底有多真实，或者是否还有更多我不知道的问题关于。那么，为什么通常不使用胖二进制文件来创建多体系结构和/或多OS软件的实际原因是什么？（Apple以外）

胖二进制方法在以下情况下最有意义：

1. 两种架构共存于同一系统上
2. 所有架构的其他所有内容或多或少都是相同的

这就是为什么它们不用于跨平台代码（两个条件都不适用）或不支持使用一个二进制文件的不同Linux发行版的原因（1.不适用，2。在一定程度上适用）。

在Linux上，如果要在单个Linux发行版上同时支持32位和64位，则这两个条件仍然适用。但是，如果您已经必须支持多个发行版，又何必麻烦呢？

在Windows上，最初是从Windows NT的引入开始发生从16位到32位的转变，这在许多方面（虚拟内存，多用户访问控制，API更改...）与16位Windows世界大相径庭。经过所有这些更改，最好将32位和16位世界分开。NT已经有了“子系统”的概念来支持不同的操作系统“角色”（Win32，POSIX），因此使Win16成为第三个子系统是一个直接的选择。

从Win32到Win64的过渡并未涉及类似的重大更改，但是Microsoft无论如何都使用了类似的方法，这可能是因为它已经过验证和尝试。

互联网时代的分配物流通过两种方式抑制了胖二进制文件：

1. 销售点不涉及实物商品，因此，当产品争夺零售货架空间且客户进行购买的机会有限时，则倾向于较少的SKU。

2. 带宽成本有利于仅交付特定软件包所需的最少必需位。通过电线传送胖二进制文件会降低客户体验和卖方基础架构效率。

当软件缩小包装的物理介质时，胖二进制文件更有意义。

胖二进制文件未成功的部分原因是，有超过ABI和处理器（实际上是指令集）的规范来使​​二进制可执行文件无效。二进制可执行文件通常在很大程度上依赖于其他资源，特别是动态库（请参见DLL hell），外部服务（如PostGreSQL之类的DBMS） ....），系统配置（例如/etc/Linux 下配置文件的位置）等。等...

仅对于Linux / x86-64，实际上很难使二进制可执行文件能够在每个Linux发行版上运行（因为它通常与libc或的特定版本绑定libstdc++）。FatELF存在，但不是很成功。

即使使用了明确定义的ABI和指令集，各种处理器品牌上的优化效果也会有所不同-请参见GCC的-mtune=native x86优化标志。

苹果公司之所以成功地拥有胖二进制文件，部分原因在于它们提供了一个非常封闭的计算资源生态系统。

自由软件是解决可移植性问题的另一种方法：如果应用程序是自由软件（经过精心编码以实现可移植性），则很容易将其移植到类似系统中。即使原始源代码无法在您的系统上正常工作，您也可以通常合理地轻松地调整它（或付钱给某人来完成工作）（当然，绑定到特定OS或ABI或处理器的免费软件也不容易端口，您将为此付出更多的努力）。以及POSIX或Linux Standard Base之类的标准也有帮助。

^{您可以付钱（或要求）某人移植一些带有可用源代码的（免费）软件，但是移植二进制可执行文件是不现实的。}

最后，存在几个框架来帮助移植到多个操作系统上（提供可用的源代码），例如Qt和POCO。

即使使用了明确指定的字节码（如JVM）也并不总是可移植性的保证：众所周知，某些Java应用程序不可移植（例如，因为它们期望某些特定的文件层次结构和命名）。

顺便说一句，今天的计算机系统的异构性可能比1980年代或1990年代初（或大型机时代）要少得多。

最后，胖二进制文件很胖：您将花费大量资源（构建时间，带宽，可执行文件大小）来解决可能不会引起很多人关注的可移植性问题。请记住以下格言：“没有便携式软件，只有移植的软件”（针对某些特定系统）。