为什么不同系统不能兼容同一个已编译的可执行二进制文件？

一个可执行的二进制文件包含的不仅仅是机器指令，还包括各种数据、程序运行资源，机器指令只是其中的一部分。

一个可执行文件要被执行的时候，操作系统需要为其分配资源，这些资源包括：内存空间（物理的和虚拟的），进程、线程资源等等，其中可执行文件的机器指令一般都放在代码段（汇编语言里称之为text段），其它资源可能放到数据段以及其它段里，这里“段”（segment）可以大致的理解为一段内存范围。操作系统（Windows/Linux）需要知道这个可执行文件需要多大的内存，有多少个段，分别载入到哪些内存地址上。可执行文件需要告诉操作系统，要为可执行文件准备哪些东西它才能运行。

可执行文件在执行之前，操作系统要有一些准备工作，因为不同的操作系统，准备工作是不同的，所以可执行文件的格式不完全相同。Windows上大部分可执行文件为PE格式，Linux里大部分可执行文件为ELF格式。格式不同导致了不同的可执行文件无法跨平台直接使用。这是原因之一。

当然了，我见过网上有大神解决了一些格式不同的问题，但跨平台运行还需要解决另一个障碍，就是操作系统API不同。一个可执行文件所执行的绝大多数操作（比如：文件操作、输入输出、内存申请释放、任务调度等等）都需要与操作系统交互才能完成，而不同的操作系统使用这些操作的方法完全不同，所以这个障碍更难跨越。这是原因之二。

如果能解决以上两个原因，那么有些可执行文件理论上是可以跨Windows和Linux在x86平台上运行的，因为Intel和AMD的CPU里，主要的硬件指令（机器指令）是相同的，也就是说0101这种二进制数，是一样的。但是如果切换到ARM平台，会有更大的麻烦就是硬件指令也不同，那么就完全没办法了。

有没有可能有跨平台运行的可执行文件呢，理论上是存在的，过去的时候也有一些办法，但限制极多，比如Windows过去是支持COM格式的文件的，这个文件就没有文件头，大小不能超过64K，只能在一个16位环境里（真实的或者虚拟的）运行，是真正的裸二进制文件。Linux里某些BIN文件恰好也是裸二进制文件（有些BIN文件没有ELF头，但不是所有的BIN都是这样的）。经过一些配置以后BIN文件也是可以在Linux上运行的。于是某些精巧设计的COM/BIN文件可以在限制极多的情况下跨平台运行，但也许只能做计算，无法做输出，大小也只有64K大，并且如果要做稍微复杂点的操作，就需要两套机器代码实现。另外，很不幸的是64位环境里COM文件已经不再支持了。

主要的原因是格式不同和API不同，前者更重要一些。