INTRODUCTION
The DOS Protected Mode Interface (DPMI) was defined to allow
DOS programs to access the extended memory of PC
architecture computers while maintaining system protection.
DPMI defines a specific subset of DOS and BIOS calls that
can be made by protected mode DOS programs. It also defines
a new interface via software interrupt 31h that protected
mode programs use to allocate memory, modify descriptors,
call real mode software, etc. Any operating system that
currently supports virtual DOS sessions should be capable of
supporting DPMI without affecting system security.
Some DPMI implementations can execute multiple protected
mode programs in independent virtual machines. Thus, DPMI
applications can behave exactly like any other standard DOS
program and can, for example, run in the background or in a
window (if the environment supports these features).
Programs that run in protected mode also gain all the
benefits of virtual memory and can run in 32-bit flat model
if desired.
Throughout this document, the term "real mode" software is
used to refer to code that runs in the low 1 megabyte
address space and uses segment:offset addressing. Under
many implementations of DPMI, so called real mode software
is actually executed in virtual 8086 mode. However, since
virtual 8086 mode is a very close approximation of real
mode, we will refer to it as real mode in this document.
DPMI services are only available to protected mode programs.
Programs running in real mode can not use these services.
Protected mode programs must use the service described to
enter protected mode before calling Int 31h services.
All Int 31h functions will modify flags and the AX register.
All other registers will be preserved unless they are
specified as return values. Unsupported calls will return
with the carry flag set. Since Int 31h is set up as a trap
gate, the interrupt flag will not be modified by any Int 31h
calls except for memory management and interrupt flag
management calls. All memory management calls may enable
interrupts. Interrupt flag management calls will modify the
interrupt flag as specified by the call. All Int 31h
services are reentrant.
Some implementations of DPMI can run 32-bit 80386 specific
programs. DPMI functions that take pointers as parameters
will use the extended 32-bit registers for offsets (for
example, ES:EDI instead of ES:DI) when running 32-bit mode
programs. The high word of the 32-bit registers will be
ignored when running 16-bit protected mode programs.
DPMI services are provided by what will be referred to as
the DPMI host program. The program(s) that use DPMI
services are called DPMI clients. Generally, DPMI clients
are two categories:
o Extended Applications
o Applications that use DPMI directly
It is believed that most DPMI applications will be extended
applications. Extended applications are bound with an
extender that is the actual DPMI client and the application
calls extender services that then are translated by the
client into DPMI calls. The advantage of an extended
application over one that calls DPMI services directly is
that generally an extender will support more than just DPMI.
In fact it is recommended that extenders look for extension
services in the following order:
o DPMI
o VCPI/EMS
o XMS
o Top-down (Int 15h)
An extender can provide a single set of APIs to the actual
application and then translate them to the services that are
provided. Where the host extension services are "lacking"
in a particular function the extender must provide that
function for the application.
Figure 1 shows a picture of how this works. The
application code sits on top of a set of base extender
functions and APIs. The extender then has separate modules
for each type of extension service and code to "fill in the
slack" where services are lacking. An example of a typical
extender service is protected mode program loading. The
actual shipped application is the application code bound in
with the extender and all of its styles of client support.
The host support is generally an extension of the base OS
functions or a device driver used to extend the base OS
functions.
This document is intended to provide a definition of the
DPMI services that a DPMI host would be required to
implement and that a DPMI client would use.
Figure 1. Application/Extender/Client/Host/OS structure
+----------------------------------------------------------+
| |
| +----------------------------------------------------+ |
| | | |
| | Application Code | |
| | | |
| +----------------------------------------------------+ |
| |
| +----------------------------------------------------+ |
| | Extender Base (including APIs) | |
| | -------------------------------------------------- | |
| | DPMI | |
| | client | |
| +------------+ | |
| | VCPI | |
| | client | |
| +------------+ | |
| | XMS | |
| | client | |
| +------------+ | |
| | Top-down | |
| | client | |
| +-------------+ |
| |
+----------------------------------------------------------+
+------------+
| |
| |
| |------------+
| | |
| DPMI | |
| host | VCPI |------------+
| | | |
| | | |
| |------------| XMS |-------------+
| | EMS | | Top-down |
| | | | (Int 15h) |
+----------------------------------------------------+
+----------------------------------------------------+
| |
| Operating System (e.g. DOS) |
| |
+----------------------------------------------------+