跨平台C++二进制：Windows与Linux二进制格式差异及操作系统编译相关技术问询

Great set of questions—let’s unpack each one clearly, since there’s a lot of nuance between binary formats, system interfaces, and how hardware actually runs code.

At the most basic level, Linux and Windows use entirely different container formats for executable files. Think of these formats as "blueprints" that tell the OS how to load, organize, and run the raw machine code inside:

• Linux uses ELF (Executable and Linkable Format):
  • ELF has a flexible structure split into segments (for runtime memory mapping) and sections (for compile-time organization, like code, data, or debug info).
  • It includes a program header table that tells the kernel exactly how to map parts of the file into memory (e.g., which segments are executable, which are read-only data).
  • Dynamic linking relies on PT_DYNAMIC segments to reference shared libraries (like libc.so), with the ld-linux.so dynamic linker resolving symbols at runtime.
• Windows uses PE/PE+ (Portable Executable):
  • PE files start with a legacy DOS header (for backward compatibility with ancient MS-DOS systems), followed by an NT header that holds critical info like the target architecture, entry point, and memory layout rules.
  • It uses an import/export table system for dynamic linking: binaries list required DLLs (like kernel32.dll or ntdll.dll) and their functions, which the Windows loader resolves during process startup.
  • Entry points are specified as relative virtual addresses (RVAs), calculated against the base address the binary is loaded at—unlike ELF, which uses direct virtual addresses.

Even if we could magically make ELF and PE interchangeable, there are far bigger, insurmountable barriers rooted in how each OS interacts with programs:

• System Call Interfaces: Linux and Windows have completely separate kernel APIs. On x86_64 Linux, programs use the syscall instruction with specific register values to invoke kernel services (like creating a process or reading a file). On Windows, user-mode code calls into ntdll.dll stubs that trigger system calls, but with entirely different call numbers, argument orders, and register conventions. There’s no overlap here—you can’t call a Linux system call and expect Windows to understand it.
• Library Dependencies: A typical Linux program relies on the GNU C Library (libc.so) for standard functions like printf or malloc, while Windows programs use the Windows API via DLLs like kernel32.dll. These libraries expose totally different functions and argument structures; even a simple file read operation uses different calls on each OS.
• Calling Conventions: The rules for passing arguments between functions differ. Linux uses the System V AMD64 ABI (arguments in registers like rdi, rsi), while Windows uses its own x64 calling convention (arguments in rcx, rdx, etc.). Mixing these would cause stack corruption and immediate crashes.
• Runtime Environment: Everything from process initialization, memory layout restrictions, environment variable handling, to file path semantics (forward slashes vs. backslashes) is distinct. A binary built for Linux would fail to find required libraries, initialize its runtime correctly, or interact with the kernel on Windows, and vice versa.

Let’s clear up a critical confusion here: binary file formats (ELF/PE) are just containers for machine code, and machine code itself is what the CPU executes directly.

• When Microsoft compiles a new Windows kernel or update, tools like MSVC translate C/C++ source code into raw x86_64 (or ARM) machine instructions. That machine code is then wrapped in a PE format container, which tells the Windows bootloader and kernel how to load the code into memory, resolve internal dependencies, and set up the execution context.
• Similarly, Linux distributions compile the kernel using GCC or Clang, which generate the same x86_64/ARM machine code—but wrap it in ELF format instead.
• The hardware doesn’t care about ELF vs. PE—it only understands the raw machine code once it’s loaded into memory. The OS’s loader (part of the kernel or boot process) is responsible for parsing the binary format, extracting the machine code, setting up memory segments, and then telling the CPU to start executing at the entry point.
• The "unified" piece here is the CPU’s instruction set architecture (ISA). For example, any x86_64 machine code (regardless of whether it was wrapped in ELF or PE) will run on an x86_64 CPU—if the OS loader knows how to unpack the container and set up the execution environment correctly.

内容的提问来源于stack exchange，提问作者user18812922