A four-part walk through the Windows Portable Executable format and the loader that turns it into a running process. From source code, through the file, into mapped memory, and on to the program's entry point.
Most introductions to the PE format drop you onto page one of the spec and start naming fields. This series goes the other way around. We begin at a source file, watch the compiler and linker build an executable from scratch, dissect the resulting binary byte by byte, follow the kernel as it maps the image into a fresh address space, and finally trace every step the user-mode loader takes before main runs.
Each part is readable on its own, but they're written to be read in sequence.
Before we can talk about how Windows loads an executable, we need to talk about how that executable came to exist in the first place. Four tools, a stack of intermediate files, and a quiet handoff that almost no one watches.
Headers, sections, data directories, and the three different kinds of "offset" the format insists on using interchangeably. We open a real binary in a hex editor and read it byte by byte.
What changes when 39 KB on disk becomes 68 KB in memory. Alignment, page permissions, and the surprising fact that Windows doesn't eagerly copy your executable into memory.
Relocations, imports, TLS callbacks, and the path from "image mapped" to "entry point runs." The kernel built the foundation; the user-mode loader assembles the rest of the house before the program can start.