Ask anyone who set up games on DOS in the early 1990s about “memory management” and you’ll probably get a wince before an answer. Getting a game to launch at all sometimes meant editing two plain-text configuration files, juggling acronyms like EMS and XMS, and keeping a stack of specially prepared boot disks just in case. None of it was optional trivia — DOS’s memory model was genuinely restrictive, and understanding why explains a huge amount of PC gaming folklore from the era.
The 640K Problem
The original IBM PC’s processor could address a full megabyte of memory, but DOS and the system architecture only left 640 kilobytes of that for actual programs. The remaining 384 kilobytes above that line was reserved for video memory, expansion ROMs, and other system needs. This became known as the 640K barrier, and as games grew more ambitious — more graphics, more sound drivers, bigger levels — that ceiling started to genuinely constrain what a game could do, even on machines with several megabytes of physical RAM installed.
Conventional, Upper, and Extended Memory
DOS-era memory came in a few distinct flavors, and each had its own rules. Conventional memory was that first 640K, directly usable by any DOS program. Upper memory referred to the reserved space between 640K and 1MB, normally off-limits but sometimes reclaimable in small pieces for drivers. Extended memory was everything above the 1MB mark — plentiful on any 286 or better machine, but not directly usable by real-mode DOS programs without special handling, since the processor had to switch into a different operating mode to see it at all.
Why 640K Felt So Arbitrary
Part of what made the barrier so frustrating is that it wasn’t a hard physical limit on the hardware itself — later PCs could easily be built with several megabytes of installed RAM. The 640K ceiling was a decision baked into the original IBM PC’s memory map back in 1981, when nobody involved expected software to ever need anywhere close to that much space for a single program. By the time games routinely wanted more, that early design decision had become deeply embedded in how DOS itself worked, and unwinding it wasn’t something any single patch or driver could fully solve — it needed workarounds layered on top of the existing system instead.
Expanded Memory (EMS): The Bank-Switching Workaround
The Expanded Memory Specification, developed jointly by Lotus, Intel, and Microsoft, solved the addressing problem with a trick: a small 64-kilobyte “page frame” inside upper memory acted as a window that could be rapidly swapped, or bank-switched, to expose different chunks of extra RAM as needed. A driver called an expanded memory manager — EMM386.EXE was the common one — made this work. It wasn’t elegant, and it added overhead, but it let programs use far more memory than 640K should have allowed, and many DOS games, especially strategy and RPG titles with large game states, relied on EMS being configured correctly.
Extended Memory (XMS): A Cleaner Path
Extended Memory Specification took a more direct approach, letting programs briefly switch the processor into protected mode to access memory above 1MB, then hand control back to DOS. HIMEM.SYS became the standard driver for exposing XMS, and it’s a line that shows up in nearly every surviving CONFIG.SYS file from the era. Some games wanted EMS, some wanted XMS, and a frustrating number wanted both configured in specific amounts — get it wrong and you’d get anything from a cryptic error message to a system that locked up on launch.
Loading High: Freeing Up Conventional Memory
Later versions of DOS added another piece to the puzzle: the ability to load drivers and memory-resident programs into the small pockets of reclaimed upper memory instead of conventional memory, using commands like DEVICEHIGH in CONFIG.SYS and LOADHIGH in AUTOEXEC.BAT. This mattered because every driver a game needed running — mouse support, CD-ROM access, network drivers — ate into that same precious 640K conventional memory pool. Squeezing those drivers into upper memory blocks instead could be the difference between a game launching cleanly and it refusing to start with an “out of memory” error, even on a machine with plenty of total RAM installed.
Boot Disks: The Gamer’s Toolkit
Because no single CONFIG.SYS and AUTOEXEC.BAT setup satisfied every game’s memory demands, many PC owners kept a collection of bootable floppy disks, each with a different memory configuration tuned for a particular title or genre. Flight sims might need maximum conventional memory with EMS disabled entirely; a sprawling strategy game like X-COM: UFO Defense might need both EMS and XMS carefully balanced. Utilities like MemMaker attempted to automate this tuning, with mixed success — trial and error remained the reliable method for most gamers.
Why Some Games Insisted on Both
The most demanding titles wanted EMS and XMS configured simultaneously, in specific amounts, because different parts of the program used different memory types for different jobs — game data might live in expanded memory while a sound driver or network stack expected extended memory, or vice versa. Getting both allocations right, without starving conventional memory of what it needed to run the executable itself, was genuinely difficult manual arithmetic, and it’s a big part of why a piece of paper taped inside a PC case listing “which boot disk for which game” was such a common sight in the early 1990s.
How DOSBox Makes All of This Irrelevant
DOSBox sidesteps the entire problem by emulating a system that simply has ample conventional, expanded, and extended memory available by default, with both EMS and XMS support built in and configurable through simple settings in its configuration file rather than through fragile driver stacking. If you want to go further and tune those settings for a particularly stubborn game, our advanced DOSBox configuration guide covers the practical side. It’s a small miracle of modern convenience: the exact headache that used to eat an entire evening before you could even start playing now resolves itself before the game window opens.