Follow a Program: from `./server` to the First Instruction

Here is the sequence on a Unix-style system. Each step is a place where the launch can fail with a specific error, and each step leaves state behind that the rest of the program’s life depends on. The lessons linked from each rung go one level deeper.

The shell is an ordinary process. It reads ./server, sees a path (not a builtin like cd), and asks the kernel for a copy of itself with fork(). The kernel creates a second process that is, at that instant, an exact duplicate: same code, same open descriptors, same environment. Copying is lazy — the pages are shared copy-on-write, so a fork of a large shell costs microseconds, not a memory copy (see Copy-on-Write).

In the child, the shell calls execve("./server", argv, envp). This is the step that replaces the shell’s image with the server’s. The PID does not change, the parent does not change, and descriptors 0, 1 and 2 survive — which is exactly why redirections like ./server > log.txt work: the shell opens the file and moves it to descriptor 1 *before* exec, and the server inherits it without ever knowing.

The parent shell then calls wait() and blocks until the child exits, which is why your prompt does not come back until the server stops (or until you append &, in which case the shell skips the wait and the child runs as a background job).

The kernel reads the first bytes of the file. \x7fELF means an ELF executable; #! means a script and the interpreter on that line is exec’d instead, with the script path as an argument. A file without a recognised header fails with ENOEXEC ("Exec format error"), and a file without the execute bit fails with EACCES before any bytes are looked at.

ELF program headers list segments: a read-execute segment for machine code, a read-only one for constants, a read-write one for initialised globals, and the size of the zero-initialised region (BSS). The kernel does not copy these into RAM; it creates *mappings* in a brand-new page table saying "virtual address 0x401000 corresponds to file offset 0x1000, permission r-x". The first time an instruction at that address executes, the CPU takes a page fault and the kernel reads that page from the file. A 50 MB binary that only runs a small path touches only a small fraction of its pages.

If the binary is dynamically linked — which is the default — the program header names an interpreter, typically /lib64/ld-linux-x86-64.so.2. The kernel maps that too and sets the entry point to the interpreter, not to your program. The dynamic linker then runs in user space: it reads the list of needed libraries (libc.so.6, libssl.so.3 …), maps each one, resolves symbols, and fills in the jump tables (the GOT/PLT) so that a call to printf lands in libc. Only then does it jump to your program’s _start. A missing library fails here, after exec succeeded, with "error while loading shared libraries".

Before handing control to user space the kernel maps a stack region near the top of the address space and writes onto it the things main will need: argc, the argv strings, the environment strings, and the auxiliary vector (page size, the address of the vDSO, a random canary seed). It records the initial program break — the end of the data segment — which is where the heap will grow from once malloc first calls brk. Both the stack and the heap are nearly empty at this point; they are reservations of virtual addresses, not RAM.

Finally the kernel sets the new process’s saved register state: instruction pointer to the entry point, stack pointer to the top of that stack, everything else zeroed. The process is marked runnable and placed on a ready queue. It does not run yet. When the scheduler picks it (typically within a millisecond on an idle machine, but under load it could wait a full time slice), the kernel loads those registers and returns to user mode, and the CPU executes the first instruction at _start.

_start is not your code: it is the C runtime’s startup stub, which sets up stdio, runs static constructors, and calls main(argc, argv, envp). When main returns, the same stub calls exit(), which flushes buffers, runs atexit handlers and makes the exit_group system call. The kernel tears the address space down, closes descriptors, and keeps only the exit status for the parent to collect — the zombie state described in Process States.

Windows has no fork. CreateProcess(path, cmdline, …) does the whole thing in one system call family: it opens the executable (PE format, not ELF), creates a new process object and a new address space, maps the image, creates the initial thread, and starts it. Handle inheritance is opt-in per handle rather than everything-by-default, and the child receives the command line as one string that the C runtime later splits into argv.

The consequences show up in portability layers. Python’s multiprocessing defaults to fork on Linux (cheap, inherits everything) but must use spawn on Windows (start a fresh interpreter, re-import the module, pickle the arguments) — which is why a script that "works on Linux" can fail with pickling errors on Windows. Node’s child_process.fork() is a spawn with an IPC channel on every platform and has nothing to do with the Unix fork.