为不同操作系统编译的程序之间的差异

Question

从编译代码的角度来看，为一个操作系统编译的程序与另一个（例如 Linux 与 Windows）有什么区别。程序不是直接在cpu上运行的吗？还是因为程序需要引用操作系统特定的库？

Answer 1

普通编译的程序会在 CPU 上“直接运行”，但程序不会在真空中运行：

1. 许多程序依赖于外部的、动态加载的库（DLLs或.so库）。链接它们的方式取决于编译器/链接器，每个操作系统都有不同的标准。但是，也有“静态链接”程序提供所有自己的代码。

2. 现代操作系统不会将计算机的完全控制权交给正在运行的程序。程序依赖“系统调用”进行 I/O、访问硬件以及诸如信号和进入睡眠状态之类的事情。可用的服务和接口由操作系统定义。操作系统还控制允许程序使用系统的哪些部分（内存、寄存器、中断）。

3. GUI 程序还必须在图形用户环境中工作才能在屏幕上绘制自己。但是您可能已经考虑过这个问题。

由于这些原因，独立于操作系统的应用程序必须依赖某种“虚拟机”，例如由 java 运行时提供的虚拟机。至关重要的是，VM 为操作系统资源（i/o、信号等）提供了标准接口。当然，java或python也解释“字节码”，而不是处理Intel的指令集的怪癖；但那是另一回事了。

Answer 2

不同的操作系统也有不同的功能。Windows 有 I/O 完成端口，Linux 没有。FreeBSD 有 kqueue，Linux 没有。Linux 有 futex，Windows 没有。他们也有不同的方式来做同样的事情——你传递什么参数来打开一个文件？他们是按什么顺序进的？您具体如何调用操作系统的“打开文件”功能？

Answer 3

通常，由于应用程序二进制接口 (ABI)的差异，程序不兼容。

程序不是直接在CPU上运行的吗？

不！这是操作系统的工作，以防止应用程序“直接”在 CPU 上运行。通常，在最低级别（即构建 OS API 的级别），应用程序与操作系统的内核交互。

是因为编译的程序本身需要引用操作系统特定的库吗？

是的。许多操作系统库的编写是为了方便与操作系统本身的接口，但也有许多是为跨平台编写的。这些对开发人员隐藏了低级操作系统接口，并假设该操作系统的编译版本将在运行时可用（见下文）。

虽然库可以写在一个跨平台的方式，在编译时它们不能运行的跨平台。它们仍然需要为特定的目标操作系统重新编译，再次利用操作系统（内核）的特定底层组件。

一个操作系统的编译程序与另一个操作系统有什么区别？

最后，可执行文件本身通常包含非常特定的二进制加载头文件等（例如，Windows的PE 可执行文件格式 [.exe、.dll 等...] 或Linux 的ELF [无、.o、.so] ， 等等...]）。这些还可以包括为特定软件库加载已编译的特定于操作系统的二进制文件的代码。

最后，从程序员的角度来看：调用约定。编译后的代码以特定的方式（即通过寄存器或堆栈）以非常特殊的顺序将变量传递给函数。即便如此，还需要就谁负责“清理”函数调用（调用者还是被调用者？）达成一致。尽管有多种标准且广泛使用的x86 调用约定，但某些操作系统可能不支持某些约定（这是 ABI 的一部分）。