DPMI on FreeDOS: How Protected-Mode Programs Coexist with Real-Mode DOS

FreeDOS is fundamentally a real-mode DOS-compatible operating system, yet DJGPP programs and many late DOS applications execute 32-bit protected-mode code and address memory beyond the first megabyte. The bridge is the DOS Protected Mode Interface (DPMI): a standard API through which a client asks a DPMI host to manage descriptors, memory, interrupts, exceptions, and transitions back to DOS services.

The host and client have separate jobs

A protected-mode executable or its stub is the DPMI client. A DPMI host establishes protected mode and implements services through interrupt 31h. Under historical Windows DOS boxes, Windows supplied the host. On plain FreeDOS, a program may load a host such as CWSDPMI when one is not already present.

The host does not replace FreeDOS file handling. A client that needs INT 21h must ask DPMI to simulate or call the real-mode interrupt, translating pointers between its linear address space and a DOS-accessible memory block. The FreeDOS kernel remains the provider of DOS API behavior.

Selectors replace direct segment arithmetic

Real-mode addresses combine a segment and offset, with physical address approximately segment × 16 + offset. Protected mode uses segment selectors that index descriptor tables. A descriptor defines base, limit, access rights, and other attributes.

DPMI allocates Local Descriptor Table entries and lets a client set permitted properties. A flat 32-bit runtime commonly arranges selectors whose base is the program’s linear base and whose limit spans its address space, so ordinary C pointers can be 32-bit offsets. That convenience does not make every physical address accessible; privilege and mapping rules still apply.

DOS memory and linear memory are different pools

DPMI functions allocate conventional DOS memory when a buffer must be visible to real-mode DOS or a driver. Other functions allocate linear memory for protected-mode use. The host can back linear memory with RAM and, when implemented, disk-based virtual memory.

real-mode/DOS block: segment plus protected-mode selector
linear block: handle plus linear base, managed by the DPMI host

Programs must free each resource with the matching function. Passing a selector where a segment is required, or a linear handle where a DOS block is expected, is not a harmless type mismatch; it can leak resources or fault.

Interrupts cross an architectural boundary

Hardware still generates interrupts, but handlers can exist in real or protected mode. DPMI virtualizes interrupt vectors and defines calls for installing protected-mode handlers, invoking real-mode procedures, and allocating real-mode callbacks that enter protected code.

A callback must preserve the required register and stack conventions, remain resident for as long as real-mode code can call it, and avoid pageable state when the host requires locking. Sound, network, and timer code often exposes timing assumptions that an emulator or host handles differently from real hardware.

Exceptions are evidence, not “random DOS crashes”

Protected mode produces exceptions such as page fault, general protection fault, invalid opcode, and stack fault. The DPMI host can reflect them to a client’s handler or terminate the client with a register dump. DJGPP/CWSDPMI messages that show an exception address, error code, and registers are debugging material.

Symbol information and the exact executable matter. A page fault can mean a null/uninitialized pointer, an invalid selector, or a host/resource problem; increasing memory managers does not repair an invalid pointer.

DPMI version and host implementation matter

DPMI 0.9 established the widely implemented base; 1.0 added services and defined error reporting more fully. A program must query capabilities and tolerate unsupported optional functions. “DPMI available” does not mean every host implements identical virtual memory, physical mapping, debugging, or interrupt behavior.

Do not load two competing hosts. First reproduce with a clean FreeDOS boot, one documented XMS manager, the application’s supplied/recommended DPMI host, and no unrelated TSRs. Record CPU, emulator/hardware, FreeDOS kernel, host version, available conventional/XMS memory, and exact error.

DPMI allowed sophisticated 32-bit software to coexist with DOS by standardizing the dangerous boundary. Compatibility comes from respecting that boundary—not from pretending a protected-mode program is just a larger real-mode .EXE.

Related:

Sources: