为何可执行文件需二进制格式规范？相关技术疑问解析

Hey there, let's unpack these three questions—they get right to the core of how operating systems interact with executable code. Let's go one by one:

1. Why do binary codes need independent format specifications (like ELF for Linux, PE for Windows)? #

Put simply, these formats act as a standardized "rulebook" between your compiled program and the operating system's loader. Here's why they're non-negotiable for modern systems:

• The kernel needs clear instructions to load the program correctly: it has to know where the executable code lives (.text section), where initialized data is (.data), where uninitialized data should be allocated (.bss), and what the entry point (the first instruction to run) is. Without this structure, the kernel would have no way to parse a blob of machine code into something it can execute.
• They handle dependencies: formats like ELF and PE include metadata about shared libraries (like libc.so on Linux or kernel32.dll on Windows) that the program needs to run. The loader uses this info to find and load those libraries before executing the main program.
• They support modern OS features: things like address space layout randomization (ASLR), memory permissions (making code sections read-only to prevent exploits), and debugging symbols all rely on metadata stored in the binary format.
• They enable tooling: compilers, linkers, debuggers (like gdb or WinDbg), and package managers all depend on these standardized formats to work consistently across programs.

2. Is it possible to develop an OS and its programs without relying on such binary format specifications? #

Absolutely—but it's extremely limited and not practical for modern, general-purpose systems. Here's how it could work:

• Bare-metal binary execution: You could write a program that's just raw machine code, with no metadata. A simple bootloader or tiny embedded OS could load this binary into a fixed memory address and jump to the start of it. Early DOS programs (before PE) worked something like this, relying on fixed memory offsets.
• But the tradeoffs are huge: you lose all support for dynamic linking, memory protection, ASLR, debugging symbols, and modularity. Every program would have to include all its dependencies (like standard library code) directly in the binary, leading to bloated executables. Debugging would be a nightmare, since there's no metadata to map machine code back to your source code.
• For specialized use cases (like a tiny embedded controller running a single fixed program), this might make sense. But for any OS that needs to run multiple, complex programs, standardized binary formats are essential to manage complexity.

3. Are binary formats architecture-dependent? #

Yes and no—it depends on which part of the format you're looking at:

• The underlying machine code is always architecture-dependent: The actual executable instructions in the .text section are specific to the target CPU (AMD64, ARM, RISC-V, etc.). A binary compiled for AMD64 will never run on an ARM chip, no matter what format it's in.
• The format's structure can be partially architecture-agnostic: Formats like ELF are designed to be cross-architecture. The high-level structure (sections, segments, dynamic linking metadata) is the same across different CPUs, but some low-level details are adapted to the architecture:
  • ELF has 32-bit and 64-bit variants to match the CPU's address size.
  • Certain header fields (like the machine type identifier) specify which architecture the binary is intended for.
  • Alignment requirements for sections/segments may vary based on the CPU's memory access rules (e.g., AMD64 requires 16-byte alignment for certain instructions).
• PE, on the other hand, is more tightly tied to Windows and x86/x86_64 architectures, though it does have limited support for ARM now.

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