DOS Protected Mode Interface

DOS Protected Mode Interface (DPMI) is a software interface specification that allows Intel 286 and later compatible processors to run DOS programs in protected mode that takes advantage of the extra capabilities of the newer processors, rather than to rely on the real mode that emulates the functionality of the original 8086 and 8088 processors. This allowed DOS programs to take advantage of extended features offered by the later processors families including the ability take control of all available system memory. Microsoft Windows also used DPMI for some of the networking code in versions 3.x of the system and also internally for some of the interfaces that allowed 386 code to run.

DPMI was originally an internal development by Microsoft that was supposed to allow DOS programs to be run as tasks in the upcoming Windows version 3 but still take advantage of larger than 640kb of memory. There existed an older standard called VCPI that worked but had some problems, a number of American software houses had gotten together and developed an improved standard called XVCPI before Microsoft announced the upcoming DPMI. Faced with a similar debacle as existed with extended/expanded PC memory standards of the 80s, the industry group agreed to team up with Microsoft and IBM and the two standards were merged into the DPMI 0.9 standard that virtually all DPMI servers and client software follows.

The VCPI standard assumed that the client DOS program could be the only program running on the computer and therefore allowed VCPI client programs to take full control of the computer including taking over ring 1 or ring 0 of the processor, the DPMI standard however was designed from the outset to allow the use of extended DOS programs under a multitasking operating system. DPMI therefore assumes there is an operating system or a kernel of some sort that owns ring 0 and only allows the DOS client software to use resources allocated to ring 3 (userland), there were custom versions of DOS DPMI extenders made for games software developers that allowed them to take control of ring 1 in order to eek out the absolute last drop of performance from DOS based system, but these were not distributed to end users or developers.

The OS/2 implementation of the DPMI server
The OS/2 DPMI virtual host is really an excellent implementation and just about the most compatible one out there, as with anything in this world there have been some minor niggles including:
 * When OS/2 2.0 was released the DPMI server allocated all the memory specified in the DPMI_MEMORY_LIMIT when a DOS program was started, no matter if it eventually used it or not, this caused both a performance decrease for the software in question as people tended to put smaller values in there than was optimal and it robbed the rest of the system of working memory. This was fixed in OS/2 2.1 and subsequent releases, where the OS now simply monitors DPMI requests for memory and allocates them as needed.
 * There was a bug that could cause a program to exit when spawning child processes in some specific cases, this is a very rare occurrence as only one development package really used this technique. This was fixed in later fixpaks of version 3 and all releases of OS/2 Warp 4 and later incorporate this fix.
 * There are other small niggles with the OS/2 implementation of the DPMI server, they are however not bugs but rather consequences of the fact that OS/2 is running DPMI as a child process, or in other words it is a virtual DPMI host rather than a "real DPMI server". That means that in a few rare cases where the program has only been developed and tested under a native DOS host and a DOS DPMI server only, user generated events such as escaping or pausing/breaking via the keyboard are trapped by OS/2 but the behaviour is not expected by the running program. The wast bulk of DPMI enabled DOS software was written or at the least tested under virtual DPMI host and represents no problems but a few packages based on DJ Delorie's DJGPP do. There was a small behaviour fix introduced in OS/2 Warp 4 Fixpak 14 and later levels, but this should rather be considered an application program bug than a problem with the OS/2 DPMI host.

DPMI related settings
As with all other OS/2 program variables, these settings can be set universally for all programs that run on your system or on a program to program basis by manipulating the individual software packages settings notebook.
 * DPMI_DOS_API:Settings are either Auto (default), Enabled, Disabled.
 * You should leave this on auto in most cases, although a few programs require you to have it enabled and if you know that a program uses DMPI you will get a tiny performance increase if you enable it in the settings notebook for the program object as the OS no longer has to monitor the program's behaviour, but since the OS monitors the program's behaviour anyway to allocate memory blocks, this is not a real issue.


 * DPMI_MEMORY_LIMIT:: This can be set from 0 to 512 megabytes in one megabyte increments, default is 4.
 * The default setting is actually enough for 99% of DOS programs that use DPMI, but a few programs such as for instance some Prolog interpreters and Ada compilers can really speed up executing large programs if they are given some more, and a few programs like dBase V for DOS refused to run unless the memory was set to 8MB and DPMI_DOS_API to on. On a modern computer the memory setting can be set very high if you like, as you will probably have one or two gigs of memory available, and the memory will not be allocated until the DPMI client requests it anyway.


 * DPMI_NETWORK_BUFF_SIZE:This is can be set from 1 to 64 kilobytes, default is 8.
 * This is only used by MS Windows networking programs running under WinOS/2, if you do not use any such you can ignore this but if you are, you can safely bump this up to 64, it will have no derogatory effect on the rest of the system.

Standards

 * DPMI 0.9 Standard - From Tenberry
 * DPMI 1.0 Standard - From DJ Delorie, note that only one or two extenders follow this version of the specification.