DOS Memory Management: Evolution and Modern Insights

1️⃣ Evolution of DOS Memory Management

When Microsoft released DOS 1.x in 1981, the operating system assumed a maximum of 64 KB of RAM. No explicit memory‑allocation API existed; programs simply ran in the single 64 KB segment that the BIOS provided. The rapid adoption of the IBM PC/XT in 1983, equipped with 128 KB–256 KB of RAM, forced a redesign. DOS 2.0 introduced the first three INT 21h services for memory handling:

• ALLOC (48h) – request a block in paragraphs (16 bytes each).
• DEALLOC (49h) – free a previously allocated block.
• SETBLOCK (4Ah) – resize an existing block (similar to realloc).

These functions created a “memory arena” that spanned from the end of the program’s static segment to the top of conventional memory. The arena was represented by a chain of Memory Control Blocks (MCBs), each occupying one paragraph and storing a signature, owner ID, and size.

2️⃣ DOS 2.11: The First Real‑World Allocator

DOS 2.11 refined the original design without changing the public API. The MCB header looked like this (excerpt from DOSSYM.ASM):

arena STRUC
  arena_signature DB ?   ; 'M' for normal, 'Z' for last block
  arena_owner    DW ?   ; 0 = free, otherwise PSP segment of owner
  arena_size    DW ?   ; size in paragraphs
arena ENDS

The signature ensured integrity: any block not marked ‘M’ or ‘Z’ triggered a fatal error, indicating memory corruption. The owner field linked a block to its Process‑Segment‑Prefix (PSP); when a process terminated, DOS automatically freed all blocks whose owner matched the PSP address.

Allocation was “first‑fit” by default: DOS scanned the MCB chain from low to high addresses, returning the first block large enough to satisfy the request. If the request failed, the function returned the size of the largest free block in BX. A common idiom was:

1. Call ALLOC with FFFFh paragraphs to discover the maximum free space.
2. Allocate the exact size returned on the second call.

SETBLOCK could shrink or expand a block without moving it. Shrinking always succeeded and freed the trailing space; expanding succeeded only if adjacent free space existed, otherwise BX reported the maximum possible growth.

3🚀 DOS 5.0 and the Rise of Upper Memory Blocks (UMBs)

DOS 5.0 (1991) introduced a game‑changing concept: Upper Memory Blocks. With the DOS=UMB switch, the OS could link memory above the 640 KB conventional limit into the allocation arena, creating two distinct arenas—one for conventional memory and one for UMBs.

To control this new landscape, Microsoft added INT 21h/58h (AllocOper) subfunctions:

• 0/1 – Get/Set allocation strategy (first, best, last fit).
• 2/3 – Get/Set the UMB link state (linked or unlinked).

Moreover, three new strategies combined with the original fit modes:

• Allocate from conventional memory only (backward compatible).
• Allocate from UMBs first, then conventional memory.
• Allocate from UMBs exclusively.

These settings were global, affecting all processes. Well‑behaved TSRs (Terminate‑and‑Stay‑Resident programs) saved the original state before changing the strategy and restored it on exit, as recommended in the MS‑DOS 5.0 Programming Reference.

4🔧 Core Functions & Allocation Strategies Explained

ALLOC (48h)

• Input: Desired size in paragraphs (AX).
• Success: Returns segment address in AX.
• Failure: AX = error code, BX = size of largest free block.

DEALLOC (49h)

• Input: Segment of block to free (DX).
• Action: Sets owner field to zero; does not coalesce.

SETBLOCK (4Ah)

• Input: Segment (DX) and new size (CX).
• Resize smaller → always succeeds, frees trailing space.
• Resize larger → succeeds only if adjacent free space exists; otherwise BX returns max possible size.

Allocation Strategies (AllocOper 58h)

By combining fit mode with UMB preferences, developers could fine‑tune memory usage for games, utilities, or multi‑tasking environments.

5🛠️ Why Retro‑Computing Enthusiasts Still Care

Modern hobbyists building DOS‑compatible VMs or restoring vintage hardware encounter the same allocation quirks documented decades ago. Understanding these details helps in:

• Debugging memory corruption – mismatched MCB signatures often point to buffer overruns.
• Optimizing TSR placement – choosing “last fit” can keep TSRs out of the way of conventional programs.
• Leveraging UMBs for modern utilities – tools like AI marketing agents can be packaged as DOS‑compatible binaries that load into upper memory, leaving the 640 KB area free for legacy apps.
• Porting legacy code to modern platforms – emulators such as DOSBox replicate the MCB chain; developers can simulate allocation strategies by toggling dos=umb in the config.

Moreover, the UBOS platform overview demonstrates how contemporary low‑code environments abstract these classic concepts, allowing developers to create “DOS‑style” memory pools inside containerized micro‑services.

6🔮 Conclusion – Legacy Lessons for Future Systems

DOS memory management may appear archaic, yet its core principles—simple linear allocation, explicit ownership, and deterministic coalescing—remain relevant in embedded systems, real‑time OS kernels, and even WebAssembly runtimes. By mastering the nuances of ALLOC, DEALLOC, and SETBLOCK, developers gain a mental model that translates to modern memory‑pool APIs.

As the retro‑computing community continues to revive classic software, the knowledge of MCB signatures, allocation strategies, and UMB linking ensures that old programs run reliably on new hardware. And for forward‑looking SaaS creators, the lessons from DOS remind us that transparent, deterministic memory handling can be a competitive advantage in performance‑critical services.