How MS-DOS 6.22 Runs DPMI Programs

MS-DOS 6.22 is a 16-bit real-mode operating system fundamentally restricted to addressing 1 megabyte of memory, meaning it cannot natively execute protected-mode software on its own. To run programs requiring the DOS Protected Mode Interface (DPMI), MS-DOS relies on third-party DOS extenders and DPMI hosts. These components bridge the gap between 16-bit real mode and 32-bit protected mode, enabling applications to bypass conventional memory limits, utilize extended memory (XMS), and run advanced x86 instructions while still using standard MS-DOS system calls.

The Real-Mode Limitation

MS-DOS 6.22 operates the processor in real address mode, limiting applications to the base 640 KB of conventional memory (and upper memory blocks up to 1 MB). Advanced applications—such as 32-bit games, compilers, and CAD tools—require protected mode to address gigabytes of linear memory and utilize hardware paging. Because MS-DOS cannot operate the processor in protected mode by default, execution requires a structured mechanism to switch processor states without crashing the operating system.

The Role of DPMI and DOS Extenders

DPMI is a standardized API that governs how protected-mode applications interact with memory managers and multitasking environments. While MS-DOS 6.22 includes memory managers like HIMEM.SYS (an XMS driver) and EMM386.EXE (an expanded memory and VCPI provider), it does not include an integrated system-wide DPMI host.

Instead, DPMI-dependent applications bundle a DOS extender (such as DOS/4GW, PMODE/W, Causeway, or Phar Lap) or depend on a separate resident DPMI host (such as CWSDPMI.EXE).

The Execution Process

When a user executes a DPMI-dependent program under MS-DOS 6.22, the execution follows a defined sequence:

  1. Stub Execution in Real Mode:
    The application file starts with a small 16-bit real-mode executable header known as a "stub." MS-DOS loads and executes this stub into conventional memory just like any standard 16-bit program.

  2. DPMI Detection:
    The stub issues a multiplex interrupt (INT 2Fh, with AX=1687h) to detect whether a DPMI host is already active in memory (for instance, if the program is running inside a Windows 3.1 DOS prompt or a third-party environment).

  3. Host Initialization:

    • If an active DPMI host is found, the program requests entry-point information and prepares to enter protected mode under that host's control.
    • If no host is found, the application's embedded DOS extender acts as its own host, or loads an external utility like CWSDPMI. The extender allocates extended memory by negotiating directly with HIMEM.SYS via the eXtended Memory Specification (XMS), or with EMM386.EXE via the Virtual Control Program Interface (VCPI).

  4. The Mode Switch:
    The DPMI host creates the necessary descriptor tables—the Global Descriptor Table (GDT) and Interrupt Descriptor Table (IDT). It then toggles the Protection Enable (PE) bit in processor register CR0, switching the CPU from real mode into protected mode (often placing the application in Ring 3 for safety, or Ring 0 depending on the extender architecture).

  5. Loading the Protected-Mode Payload:
    Once protected mode is active, the extender reads the main 32-bit application code from the executable file, places it into high extended memory, sets up the 32-bit stack, and transfers execution to the application entry point.

Servicing MS-DOS Interrupts

Because MS-DOS 6.22 kernel routines (INT 21h) and BIOS functions (INT 10h, INT 13h) are written strictly in 16-bit real-mode code, a protected-mode program cannot call them directly. The DPMI host resolves this through a process called interrupt reflection:

  1. When the application issues a service request (such as reading a file via INT 21h), the CPU catches the interrupt in protected mode.
  2. The DPMI host intercepts the call and copies any required data buffers from high extended memory down into a dedicated transfer buffer located below the 1 MB boundary in conventional memory.
  3. The DPMI host temporarily switches the processor into real mode (or Virtual 8086 mode if a memory manager like EMM386 is active).
  4. The host re-issues the interrupt to the native MS-DOS 6.22 kernel.
  5. Once MS-DOS completes the operation, the DPMI host intercepts the return, copies any output data back into extended memory, switches the CPU back to protected mode, and returns execution to the application.