the loader

The linker produces a finished executable file sitting on disk, but a file on disk cannot run; the processor only executes instructions that are in memory. Something must take that file and set it up in memory so the program can begin. That something is the loader, a part of the operating system. When you double-click an app or type a command, the loader is what springs into action behind the scenes to bring the program to life.

The loader's steps are concrete. It reads the executable's headers to learn how big the program is and how it is divided into sections (code, initialized data, and so on). It allocates memory for the process and copies, or memory-maps, those sections into the right places, setting up the read-only code region and the writable data region. It arranges the initial stack (often placing command-line arguments and environment there), sets the stack pointer, and finally hands control to the program's entry point so the first instruction runs. With virtual memory, each program is loaded as if it owns a clean address space of its own, even though many programs share the physical machine.

The loader matters as the final bridge from a built program to a running process. At orientation level, picture a clean handoff: linker makes the executable, loader places it in memory and starts it, after which the program runs. With dynamic linking the loader does extra work, because some library code was deliberately left out of the executable; a dynamic loader must find those shared libraries, map them in, and fix up the remaining references at load time before the program can use them.