为何C++可执行文件存在平台依赖性？——同架构跨系统开发疑问

Great question! Even when you’re writing strictly standard-compliant C++ code and targeting the same x86 architecture, binaries compiled for Linux won’t run on Windows (and vice versa). Let’s break down the specific, often overlooked factors that cause this:

1. Executable File Format Mismatch #

Every OS uses its own binary format that its kernel knows how to load:

• Windows uses PE/PE+ (Portable Executable) format. The Windows kernel and ntdll.dll rely on this structure to map the binary into memory, resolve dependencies, and start execution.
• Linux uses ELF (Executable and Linkable Format). The Linux kernel’s loader parses ELF headers to handle memory segments, dynamic linking, and entry points.

Even if the machine code inside is x86-compatible, the OS has no idea how to interpret the wrong file format—it’s like trying to open a .docx with a video player.

2. ABI (Application Binary Interface) Differences #

The ABI is the "language" that compiled code uses to talk to other code (libraries, the OS, etc.). It varies drastically between Windows and Linux, even on x86:

• Calling Conventions: Rules for how function arguments are passed (registers vs. stack) and who cleans up the stack after a call. Windows defaults to __stdcall or __fastcall for system functions, while Linux uses the sysv calling convention. Mismatch here leads to immediate crashes when functions are called.
• Name Mangling: C++ compilers mangle function names to handle overloading. MSVC (Windows) and GCC/Clang (Linux) use completely different mangling schemes—so a function like void foo(int) will have a totally different symbol name in each binary, making cross-platform linking impossible.
• Memory Alignment: While the C++ standard defines basic alignment rules, platforms often use different default alignments for types like structs. A struct compiled on Windows might have padding that’s different from the same struct on Linux, leading to corrupted data when accessing members.

3. Runtime Library Dependencies #

Even "platform-agnostic" C++ code relies on the standard library, which is platform-specific:

• Windows uses libraries like msvcrt.dll or ucrtbase.dll for its C/C++ runtime. Linux uses libstdc++ (GCC) or libc++ (Clang). These libraries have different internal implementations, symbol names, and initialization logic. For example, std::cout on Windows hooks into the Windows console API, while on Linux it uses write() system calls under the hood.
• Program Startup Code: Compilers inject hidden startup code to initialize the runtime, set up the stack, and call your main() function. Windows uses WinMain or a crt0-style startup, while Linux uses _start as the entry point. This code is hardcoded to work with the target OS.

4. System Call Mechanisms #

Even if you don’t call OS APIs directly, the standard library does. Windows and Linux have completely different system call interfaces:

• Windows uses a set of numbered syscalls (invoked via the syscall instruction on x86-64) that are unique to its kernel. Linux has its own set of syscall numbers and calling conventions. For example, opening a file via std::fopen will eventually call Windows’ CreateFileW or Linux’s open syscall—these are baked into the binary at compile time.

5. Implicit OS Assumptions #

Small, easy-to-miss details can also lock your binary to a platform:

• File path separators (Windows uses \, Linux uses /) are handled differently by the standard library’s file I/O functions.
• Environment variables have different names and behaviors (e.g., PATH works similarly but is populated differently on each OS).
• Signal handling (like SIGINT for Ctrl+C) has different implementations and default behaviors.

In short, even with the same CPU architecture, the OS’s binary loading rules, ABI, runtime libraries, and system call interfaces create hard boundaries between platforms. That’s why cross-platform C++ development relies on tools like CMake (to generate platform-specific build files) or cross-compilers (to build binaries for one OS from another).

内容的提问来源于stack exchange，提问作者F.Jean