DOS Protected Mode Interface

DOS Protected Mode Interface
Name	DOS Protected Mode Interface
Abbreviation	DPMI
Developer	Microsoft, Microsoft Windows, Lotus Software, Intel Corporation
Introduced	1989
Type	Application programming interface
Related	DOS extenders, Real mode, Protected mode, Virtual 8086 mode

DOS Protected Mode Interface is a standardized application programming interface that enabled MS-DOS programs to run in protected mode on x86 processors while retaining DOS services and compatibility with legacy BIOS and MS-DOS real‑mode software. It provided a consistent mechanism for memory management, interrupt handling, and switching between real mode and protected mode for commercial software such as Borland C++, Watcom C/C++, Microsoft Visual C++, and Turbo Pascal-based products. DPMI was adopted by various vendors and became central to the ecosystem of DOS extenders and development tools during the late 1980s and early 1990s.

Overview

DPMI defined functions and data structures that allowed programs to request services from a DPMI host or server, enabling protected‑mode applications to use DOS interrupts, BIOS calls, and physical memory above 1 MB while running on processors like the Intel 80286, Intel 80386, and later Intel Pentium. The specification separated responsibilities between a DPMI host (often an operating system or extender) and a DPMI client (the application), clarifying how memory management and task switching were mediated. Major players in adoption included Microsoft, Novell, IBM, and compiler vendors such as Borland and Watcom.

History and Development

DPMI emerged as a response to limitations of real‑mode MS-DOS and the need to exploit the Intel 80386 protected‑mode features for larger applications, multitasking environments, and database systems like dBASE and Oracle Database. Early DOS extenders such as Qualitas, DOS/4GW, and implementations by Rational Systems led to vendor discussions that included Microsoft and the Open Software Foundation community. The specification process involved stakeholders from Lotus Software, Symantec, Novell, and compiler authors to reconcile competing designs such as the VCPI interface and other extension mechanisms. DPMI’s formalization around 1989–1990 coincided with the rise of graphical environments like Microsoft Windows 3.0 and multitasking projects such as Concurrent DOS and influenced later designs in operating systems and virtualization.

Architecture and Features

The DPMI architecture specified a host‑client model, where the host implemented services for clients to allocate selectors, map selectors to linear addresses, set up interrupt and exception handlers, and perform far returns to real mode or virtual 8086 mode. It defined fixed calls for services including memory allocation, selector manipulation, descriptor tables such as the Global Descriptor Table, and interrupt thunking for BIOS and DOS compatibility. The interface addressed differences between 80286 and 80386 processors by defining methods for protected-mode switching, use of paging, and support for flat memory models used by compilers from Microsoft Visual C++, Borland C++, and Watcom.

Programming Model and APIs

Applications interacted with DPMI via software interrupts and function descriptors, invoking routines to allocate physical pages, create call gates, and map physical memory into protected‑mode selectors. Compiler suites such as Borland Turbo C, Microsoft QuickC, Digital Research tools, and Watcom provided runtime libraries and headers to simplify use of DPMI services. DPMI also specified how to handle hardware interrupts, exceptions, and timer services so that applications like games and CAD packages could coexist with MS-DOS drivers and BIOS-level routines. Toolchains integrating debuggers and linkers from Borland and Microsoft supported generation of DPMI‑aware executables.

Implementations and Toolchains

Popular DPMI hosts and extenders included DOS/4GW (bundled with many id Software titles), CWSDPMI, HDPMI, PMODE/W, and Windows 3.x when running in enhanced mode. Compiler and linker support came from vendors such as Borland, Microsoft, Watcom, and DJGPP (which used DPMI servers like CWSDPMI). Toolchains integrated with build systems and development environments from Microsoft Visual Studio predecessors and Turbo Pascal IDEs, enabling commercial software vendors and game developers to target protected‑mode DOS while maintaining access to legacy services.

Compatibility and Limitations

While DPMI provided substantial compatibility, it had limitations related to interrupt remapping, driver expectations, and hardware access patterns used by some DOS applications and games that assumed unfettered real‑mode control. Differences between DPMI hosts produced subtle behavioral variations affecting low‑level code, which led developers to test against specific hosts such as DOS/4GW and CWSDPMI. The reliance on x86 protected‑mode semantics meant DPMI was tied to architectures like Intel x86 and incompatible with non‑x86 platforms; evolving operating systems such as Microsoft Windows NT and virtualization technologies reduced the need for DPMI over time.

Legacy and Influence

DPMI influenced subsequent approaches to backward compatibility, virtualized execution, and operating‑system extensibility in projects such as Windows NT Virtual DOS Machine, DOSEMU, and modern emulation layers like DOSBox. It shaped expectations for how legacy software could be supported while leveraging advanced CPU features, and informed design choices in later runtime interfaces and hypervisor APIs from organizations like Intel Corporation and VMware, Inc.. Elements of DPMI’s host‑client separation echo in later application binary interfaces and compatibility layers used by open source and proprietary systems.

Category:Application programming interfaces