在大二上计算机组成这门课时，我知道了一个C程序经过编译、汇编、链接，最终生成了一个二进制的可执行文件。 我当时认为二进制可执行文件就是一些CPU可以直接进行解释的机器指令，那么如果电脑的架构相同，比如都是X86体系架构，则它们能够识别的机器指令格式就是相同的，那么能在机器A（使用Windows系统）上执行的程序应该也能在机器B（使用Linux系统）上执行才对，为什么实际并不是这样呢。 当时这个问题困扰了我一段时间，网上也没有找到满意的答案，就把它搁置起来了。一年之后，随着知识的增长，我觉得自己好像已经能够回答这个问题了。

一个可执行文件是怎么被CPU去解释执行的呢？它的指令是怎么进入CPU中的呢？答案就是这都是操作系统帮你做的，程序的指令是不会自己跑进CPU的，程序能够执行一定是在操作系统的帮助之下的。

当你简单的双击一个可执行程序时，操作系统其实帮你做了很多的事情：它读取这个程序文件并将其加载到内存中，找到程序的代码段，将CPU的PC寄存器指向这个代码段的开头，然后CPU才会开始执行程序。 而一个可执行程序想要被操作系统识别，它的内部组织就需要遵循操作系统的规定，Windows的exe文件的内部组织和Linux的out文件的内部组织是不一样的，所以Linux系统是没法识别exe文件的，这个exe程序的代码段自然没有被CPU解释执行的机会。 不过问题来了，如果仅仅是可执行程序的结构不同导致了程序没法跨平台运行，那我岂不是只要把C语言的源代码在Windows上用VC编译汇编链接一次，再在Linux上用gcc编译汇编链接一次，就可以得到两个平台版本的可执行程序了吗？但是实际生产中并不是这样，跨平台是个很头痛的事，想要得到两个平台都可用的程序往往需要分别开发。这就说明了应用程序对操作系统的依赖不仅仅是体现在可执行程序的文件格式上那么简单。

那么应用程序对操作系统还有哪些依赖呢？基本上所有需要操作计算机底层I/O硬件的功能，应用程序都没法单独完成，只能求助于操作系统。“int a = 1 + 1;” 这条指令可以被编译器（和汇编器）直接翻译为操作CPU寄存器和加法器的机器命令，如果源代码中只有这一条指令，那该应用程序不需要操作系统的帮忙。但是如果你想要打印出a的值呢？你得写下"printf("%n", a);"，这条指令转去执行C标准库中printf函数的内容，那printf又是怎么让屏幕上显示字符的呢？C标准库应该是用汇编语言编写的，所以在printf函数中有能够直接操作屏幕的汇编命令吗？ 显然没有… 根本没有这样的汇编命令。实际上，printf中用到的汇编指令很简单，就是向操作系统求助（即系统调用syscall，可以想象为调用操作系统提供的函数/API），它告诉操作系统想要打印的字符，然后操作系统去操作屏幕（和屏幕的驱动去交互），最后才能在屏幕上显示出字符。 而在不同的操作系统中，系统调用/内核API是不同的，所以C标准库需要有Windows版本和Linux版本，在各自的版本中调用各自的系统调用/内核API。 所以下面这个源代码能够在两个操作系统上都成功编译和运行是因为C标准库帮你做了跨平台部分的操作，这给你一种“我的代码和操作系统无关”的错觉。

如果你把你的这个程序源码和你调用的C标准库函数printf的源码放在一起考虑，那你实际上就是写了适用于windows和适用于linux的两套源码，只是跨操作系统部分的源码并不真的是你写的。我们假设你把适用于Windows的printf函数的源码抽取出来，放在你的源程序中，然后在Windows上编译成exe文件，再假设你可以把.exe文件用某种办法转换为符合linux标准的.out格式，这个转换后的.out还是没法在Linux上运行，因为适用于Windows的printf函数使用的系统调用Linux是肯定没法提供的。

所以，如果你的程序要实现的功能C标准库中没有提供，你就得自己写操作系统相关的代码了，比如在Windows中操作注册表就需要和Windows API去交互，C标准库中是没有操作注册表这种东西的。当然，你也可以用别人已经写好的跨平台库函数，但是你这也只不过是把跨平台的操作交给其他人写的代码去完成了。

可执行程序不能跨操作系统运行的原因总结一下就是：