How Windows 3.x Faked Protected-Mode Memory on the 8086

Before Windows 3.0, Microsoft had to make a multitasking GUI run on 8086 and 80286 chips that lacked paging, so Windows essentially acted as a sophisticated overlay manager. Segments — contiguous blocks of up to 64KB — were the unit of memory, identified by opaque 16-bit handles rather than direct addresses, mimicking the selector model Intel had introduced with 286 protected mode. Applications had to call GlobalLock to pin a segment and obtain a usable far pointer, then GlobalUnlock when done, after which Windows was free to relocate or discard the block to defragment memory.

The New Executable (NE) format made this scheme possible by storing each segment separately on disk, letting Windows load, reload, and shuffle them individually. Segments carried flags marking them as fixed or movable and discardable or nondiscardable: interrupt handlers had to stay put, code and resources were typically discardable because they could be re-read from the EXE, while writable data usually could not. Exporting a window procedure was required so Windows could patch its prologue to restore the application’s DS register — the kind of low-level detail high-level toolchains hid from most developers.

The piece is useful as preserved institutional knowledge: 16-bit Windows memory management was critical to writing anything beyond Hello World, but it was poorly documented because vendors assumed compilers would handle it. Understanding it explains quirks like FAR PASCAL declarations, mandatory exports, and the subtle bug class where code touches a segment after unlocking it and gets away with it until Windows finally moves the block.