Win16 memory management: when your allocator returns a handle, not an address

Windows as overlay manager, not just a GUI

The article's central insight is easy to miss if you only remember Windows 3.1 icons: from Windows 1.0 onward, the OS was a sophisticated overlay manager. Typical PCs could not keep all of Windows resident in RAM. Segments loaded, moved, discarded, and reloaded from the New Executable (NE) format on disk — each code and data segment stored separately so the loader could page individual pieces without swapping the entire process image.

For a Hello World with one code segment and one data segment, this was nearly invisible. Near calls and near pointers kept working while Windows shuffled physical addresses. The moment you exported a FAR PASCAL window procedure — which every real program did — you entered a contract: the OS would patch your function prolog, reload your data segment on entry, and walk your stack frames when it compacted memory. Break any part of that contract and you did not get a clean segfault. On the 8086, every address was "valid"; reads and writes always succeeded until they scribbled over something else.

Necasek traces the design to Steve Wood's Windows 1.0 memory manager, explicitly inspired by Intel 286 protected mode — years before Windows actually ran in protected mode full-time. Handles were stand-ins for selectors: opaque 16-bit IDs that survived segment motion. Programmers called GlobalAlloc to reserve memory, GlobalLock to pin a segment and receive a temporary segment address, and GlobalUnlock when done. The pointer returned by GlobalLock became invalid the instant you unlocked — but the segment often did not move immediately, so the bug hid until memory pressure forced compaction during an unrelated dialog box paint.

Why beginners were set up to fail

Tutorial books showed windows, menus, and dialogs. Memory management was glossed over even though it underpinned every non-trivial app. Microsoft C supported Windows from version 3.0 (1985), but the critical switches — /Gw for Windows prologs, /Aw for DLLs where SS != DS — were barely documented. The compiler documentation listed them and pointed to the Windows SDK, illustrating what Necasek calls the "incestuous relationship" between the languages group and the Windows team.

Exported functions needed fat prologs that looked like wasted instructions until you understood the loader patched the first three bytes to load the module's default data segment. The prolog incremented BP before pushing it — a marker so Windows could walk far stack frames when moving code segments that had called into currently executing routines. DLLs were worse: no stack of their own, always running on the caller's stack, requiring /Aw builds because DS and SS pointed at different memory.

Segment flags compounded the cognitive load. Movable vs fixed. Discardable vs non-discardable. Code segments could be discarded and reloaded from the EXE; writable data usually could not. Interrupt handlers had to be fixed. Most application segments should have been movable to let Windows defragment the heap — but unlocking too early turned your far pointer into a time bomb.

The SDK shipped diagnostic weapons for this: HeapWalker to display allocated segments and simulate low memory by allocating everything then freeing in 1K steps; Shaker (later replaced by Stress in the 3.1 SDK) to force segments to move and reveal locking bugs that only appeared under pressure. These were not optional power-user toys. They were how you learned your accounting was wrong before a customer did.

OS/2 did it with hardware; Windows did it with discipline

Necasek's comparison with 16-bit OS/2 is the article's sharpest modern lesson. Both used NE executables and Microsoft's toolchain. OS/2 ran in protected mode on the 286: a selector was simultaneously handle and address, segments could move behind the application's back, and there was no GlobalLock dance. Window procedures did not need explicit export magic; the OS did not patch your prolog or unwind stacks during compaction.

Windows on 8086 real mode approximated protected-mode semantics in software. That approximation bought compatibility with an enormous installed base and produced a generation of programmers who internalized handle indirection — the same mental model that later made Win32's thin wrappers around VirtualAlloc feel like relief, and that still echoes whenever someone argues handles are the better pointers on Hacker News.

Large allocations above 64KB added another layer: segment:offset addressing meant you could only touch 64KB at a time through one selector. Enhanced-mode Windows on the 386 stretched selector limits so compilers could coax 32-bit offsets from 16-bit selectors — a hack Raymond Chen documented years later on The Old New Thing. The through-line is consistent: when hardware lacks the abstraction you need, you push complexity into conventions, tooling, and programmer discipline.

Why this trended beside IOCCC and agent harnesses

This week's HN leaderboard is a collage of extremes. IOCCC 2025 at #1 is deliberately unreadable C you can compile and inspect. KV-cache compression at #2 is probabilistic machinery most readers will never implement. Valve's P2P regression at #4 is opaque infrastructure failing in production. Win16 memory sits in the middle as documented complexity with visible tooling — the kind of post-mortem you can learn from without a GPU cluster.

The parallel to agent-first development is uncomfortable and useful. Jane Street's terminal-centric agent workflows and OpenAI's harness engineering essays describe closed loops where the environment must stay inspectable. Win16's Shaker is the 1987 version: stress the system until latent contract violations surface. Modern agents generate code that compiles on the happy path; retro Windows documentation asks what happens when the heap compacts while your callback is mid-execution.

There is also a craft-code resonance with IOCCC's winning entries: both reward authors who understand the machine's actual rules, not the rules you wish it had. An obfuscated Game Boy emulator and a treatise on movable segments are different genres, but the audience overlap on HN is developers tired of black boxes — whether those boxes are LLM weights, Steam relay routing, or a malloc that pretends addresses are stable forever.

What to steal if you build software in 2026

You will not ship Win16 segments. You can still borrow the design instincts:

• Indirection when things move. Handles existed because memory moved. Today's equivalents are versioned APIs, immutable data with structural sharing, and explicit borrow/lifetime semantics — anything that stops callers from caching pointers into resources the system might relocate.
• Stress tools, not hope. Shaker and HeapWalker were first-class SDK citizens. If your agent harness or payment pipeline only gets tested on the happy path, schedule a Shaker equivalent: force retries, RPC 429s, and partial failures before users do.
• Document the secret switches. Microsoft's hidden /Gw and /Aw flags are a cautionary tale about knowledge locked inside one team. If your platform has "you must export the window procedure" equivalents — webhook signatures, idempotency keys, wallet adapter lifecycles — put them in the tutorial, not a footnote.
• Inspectability as UX. NE files listed segments on disk; HeapWalker showed who owned each one. Users trust systems they can audit — the same instinct behind our guide to verifying Solana payments and on-chain collectible trait hashes.

Bottom line

Win16 memory management trending on Hacker News is not "kids these days discover segmented architecture." It is a well-written reconstruction of how Microsoft simulated protected-mode semantics on hardware that lacked them — and the bugs that simulation guaranteed. Beside IOCCC craft code and agent harness hype, the article offers something rarer: a system whose failure modes were designed to be hunted with named tools, not discovered in a production incident write-up months later.

Read Necasek's full piece with the SDK screenshots in mind: Shaker shaking segments, HeapWalker draining the heap one kilobyte at a time. Then ask whether your current stack has anything equivalent — or whether you are betting that memory, networks, and model outputs will stay still because you have not called the unlock yet.

Sources: OS/2 Museum — Win16 Memory Management; The Old New Thing — allocations larger than 64KB; Hacker News discussion (June 2026). Related on Solana Garden: World Pulse; Collectibles (win16-memory-management pulse theme).