The 80286 and later processors descended from the 8088 and compatible 8086 provide an alternative mode of operation, called protected mode. Protected mode provides programs with access to much more memory space than the single megabyte of the 8088. The extra memory space provided is called extended memory. Unfortunately standard DOS programs cannot run in protected mode, and therefore cannot access extended memory directly. Many DOS applications have been adapted or written to run in protected mode, but there are memory and other overheads in doing this, so few resident system extensions run in protected mode.

DOS Protected Mode Services (DPMS) is a set of services that is designed for DOS resident system extensions to run in protected mode. DPMS provides all the benefits of protected mode operation without the headaches. DOS compatibility is not compromised, and it is easy to create resident system extensions that can adapt at initialization time to DPMS and non-DPMS configurations.

This document describes the DPMS 1.0 specification and issues raised by programming for DPMS using the DPMS 1.0 System Developers Kit (SDK). It is assumed that the reader is familiar with the Intel* x86 range of processors.

Protected Mode

Introduction to Protected Mode

For compatibility with earlier processors such as the 8088, processors that support protected mode can also run in a mode that is compatible with those processors, and this is called real mode. 386* and later processors also provide a third mode called virtual-8086 mode in which standard DOS programs can run in a semi-protected environment. For the purposes of this introduction virtual-8086 mode can be treated the same as real mode.

NOTE: The term real mode is used throughout this document to refer to both true real mode and virtual-8086 mode. DPMS clients running on a 386 or later typically run in virtual-8086 mode rather than real mode.

For most software, protected mode operation is very similar to real mode. The major difference lies in the way segments are defined and used. It is possible to write software that can operate in either mode but most standard DOS programs cannot run in protected mode. Therefore standard DOS systems must run in real or virtual-8086 mode.

It is possible to mix real and protected mode software in a system by switching modes. Transitions from real to protected mode are referred to as up, transitions in the opposite direction are down. A call-up is a call that originates in real mode, executes some code in protected mode, and returns to the real mode code. A call-down is the opposite.

Segments, Descriptors, and Selectors

Segment size is described by the maximum offset that may be accessed within the segment, which is the size minus one, and this is called the limit of the segment. Protected mode segments can be larger than 64 KB on 386 and later processors.

The values loaded into segment registers which act as offsets into descriptor tables are called selectors.

In protected mode, different segments must be used for code and data, and code segments cannot be written to.

There are two descriptor tables at any time: the Global Descriptor Table (GDT) and Local Descriptor Table (LDT). Normally the GDT would be fixed while there would be a different LDT for each task if in a multitasking system. Bit 2 of a selector determines whether the corresponding descriptor is in the GDT or LDT.

Descriptors and selectors are assigned privilege levels, from zero to three. Zero is the most privileged level and three is the least. Programs running at lesser privilege levels are prevented by the processor from loading segment registers with selectors for higher privilege segments, and so those higher level segments are protected.

Restrictions

· Memory can only be accessed via descriptors. For example, real mode software might access a byte in the PC BIOS data area by loading a segment register with 00040h, but in protected mode it must first set up a descriptor for the required segment and then load the corresponding selector.

· Segment arithmetic cannot be used. If real mode software overruns the end of a segment, it can access the memory following it by simply adding 01000h to the segment register. That cannot be done in protected mode as there is no relationship between the selector and base address values. Either the base address of the descriptor must be updated or a new descriptor must be set up to access the required memory.

Memory Mapping

By convention, addresses that may be mapped are referred to as linear addresses even when they have not been mapped. The addresses of the underlying physical blocks are referred to as physical addresses.

Protected Mode Environments

If a system is already running in protected mode then it is impossible for any other piece of software to get control of the processor. Therefore in order for protected mode applications to run, a number of standard interfaces have developed which enable protected mode software to run in an existing protected environment. The main interfaces are the Virtual Control Program Interface (VCPI) and the DOS Protected Mode Interface (DPMI).

DPMS Features

DPMS is not a DOS extender. Although it has a similar acronym and some similarities, it is not the same as DPMI. It is a minimal suite of services tailored to the needs of resident system extensions. It is possible to run such software in protected mode using one or more other interfaces, but DPMS is usually more appropriate because

· DPMS provides a consistent interface, independent of environment. It insulates its clients from environment changes caused when MS Windows runs.

· DPMS uses very little standard DOS memory.

· You can supply the DPMS server with your software for low royalty payments.

DPMS API functions include

· Calls from real to protected mode and vice-versa

· Descriptor management

· Memory management

The DPMS interface is fully re-entrant.

DPMS Clients

Client Structure

Clients typically have three parts

· Initialization code and data which is discarded when the client becomes resident.

· Real mode code and data which is the minimum that must stay in real mode memory.

· Relocatable code and data which, if DPMS is present, is moved into extended memory and runs in protected mode. This code and data may use 386-specific features such as 32-bit segments, but normally it will not, so that it can run in real mode without DPMS or in protected mode using DPMS on 80286 processors.

Initialization

· Find any DPMS server.

· Allocate protected mode descriptors.

· Allocate extended memory.

· Set the descriptors' base addresses, limits, and types.

· Relocate the code and data into extended memory.

· Fix up any calls in the real mode segment whose destination isin the code that now executes in protected mode. Replace them with callsto DPMS call-ups.

· Perform functions specific to particular clients, such asregistering as a device driver with DOS, hooking real mode interrupts,and initializing data structures.

· Free any real mode memory that is no longer required.

· Call DOS to terminate and stay resident.

The client is now resident, and either DOS or an interrupt can call it through entry points in the real mode portion. Because the client does its work in protected mode, the real mode portion may consist of little more than a DPMS call up to the protected mode portion.

In order to call any real mode function, for example to call DOS, the protected mode code must go via one of the DPMS call down functions. The call down sets all real mode registers, but any data that is passed in memory, for example, a buffer, must reside in memory that is accessible in real mode.

Some clients require DPMS, and fail to install if no server is present. Others can operate entirely in real mode if there is no DPMS server.

Overview of DPMS Functions

Descriptor Management

Clients should try to reuse the same descriptor to address different objects at different times, because it takes time to allocate descriptors and because there is a finite number of descriptors available.

Clients usually need to allocate and initialize descriptors before they enter protected mode. Use the DPMS_D_ALLOC, DPMS_D_ALIAS and DPMS_M_RELOC functions to allocate descriptors. Refer to the description of DPMS_D_ALLOC on page 2-39, DPMS_D_ALIAS on page 2-43, and DPMS_M_RELOC on page 2-66 in Chapter 2, "DPMS Function Reference." Descriptors allocated via DPMS_D_ALLOC must be initialized after allocation. Depending upon what the descriptor is to be used for, initialization is done in one of the following ways:

· Allocating linear memory via DPMS_M_ALLOC (see page 2-54) or otherwise, then calling DPMS_D_SET_BASE (see page 2-47), DPMS_D_SET_LIMIT(see page 2-48), and DPMS_D_SET_TYPE (see page 2-50) to set the descriptor to refer to that memory.

· Calling DPMS_D_ALIAS_REAL (see page 2-45) to create an alias to a real mode segment.

· Passing the descriptor to DPMS_M_RELOC (see page 2-66).

If the client terminates, it must explicitly free up descriptors using DPMS_D_FREE (see page 2-41) before terminating.

Memory Mapping Functions

If these functions are supported, then clients must use them if they need to access extended memory other than that allocated via DPMS.

For example, consider a disk cache that must run both with and without DPMS. When running without DPMS, it would typically use XMS memory. When running with DPMS, it could use memory allocated via DPMS but this would mean that the memory interface would be completely different between the DPMS and non-DPMS installations, and would also make memory lending more difficult. The cache could still use XMS memory with DPMS, but this would mean that calls to the XMS driver to do block moves to and from the memory would involve mode transitions and would therefore be slower than without DPMS. Instead, the client could lock the XMS memory it had allocated, get the physical address(es) of that memory, and call DPMS_M_MAP to map the physical memory into DPMS linear address space. It could then access the memory directly instead of via XMS block moves, meaning that the cache could be faster with DPMS than without.

Extended memory allocated or mapped via DPMS may only be accessed by the DPMS client while it is in protected mode under DPMS. Access may fail if attempted via any other interface.

Mode Transitions

The parameter block includes CS and (E)IP register values. These are the addresses of the client procedure to be called. When the called procedure returns, using a RETF or an IRET, the return goes via DPMS which performs the inverse mode change, copies the new register values back into the parameter block, and returns to the original mode code.

Most calls from real or virtual-8086 to protected mode and vice-versa are to addresses that are determined at initialization time. Furthermore, many calls require parameters to be passed in registers that would have to be stored in a DPMS register structure, if calling via the call-up or -down functions already described. There is therefore an alternative, more convenient way of making inter-mode calls.

Using the alternative method, the client registers a default procedure to be called, together with default values for certain registers, including the segment registers. This is done by passing the address of a default register structure to the server. The server fills in part of the structure with the code necessary to effect the inter-mode call, and this code also contains a client ID. The client can register almost any number of default procedures in this way; each procedure is called via the code in the corresponding default register structure.

Refer to the description of the DPMS_REG_DEF_PROT function on page 2-29, in Chapter 2, "DPMS Function Reference," for the default register structure and a full description of that type of function.

Protected mode has several advantages over real mode, only one of which is the ability to execute code in extended memory. It is feasible to switch into protected mode to execute code within the first megabyte. If the code is quite small, you may not want to relocate it.

MS Windows 3.n Restrictions

To avoid this problem, clients should allocate all memory they need before Windows loads. If the client needs to co-operate with other programs, including MS Windows, that may occasionally want memory owned by the client, hook the memory manager interface and lend memory as appropriate.

API Implementation

The only code you need to use DPMS is the code you write yourself. DPMS does not require a run-time library.

DPMS clients typically perform low-level functions, so the API is created primarily for assembly language. You can write parts of a client in a high level language, but use run-time library functions with caution as they may not be compatible with protected mode.

Sample Client Source Code

This program has extensive comments to guide you through its operation. It uses all the main DPMS features. After installation when running under DPMS, less than 400 bytes of code and data remain in real mode memory.

The sample VDISK requires XMS to run.

Server Source Code

The SDK includes the full source code for the DPMS server (DPMS.EXE) to help you debug clients and to optimize the server for use on either 286 or 386 (and above) platforms. The following tools are required in order to build the server. Caldera do not supply these tools.

· Borland Turbo Assembler (TASM) v2.51
· Borland Turbo Link (TLINK) v5.1
· MS Macro Assembler v5.10b
· MS Linear Executable Linker (LINK386.EXE) v1.00.056

In the \SOURCE\DPMS directory, edit the MAKE.BAT files so that the paths point to the correct tools on your computer. Run MAKE to build the server (DPMS.EXE). This is copied into the \SOURCE\DPMS\BIN directory.

You need at least 600 Kb of TPA to build DPMS.EXE. We therefore recommend that you use DR-DOS because of the extra TPA available. You can build the server into the DR-DOS kernel if you need an embedded solution and the DR-DOS source code is available from Caldera's web site.

DPMSTEST

The test program is straightforward to use. Enter DPMSTEST /? for a summary of its use.

DPMS Limitations

· DPMI, if present, is not available to DPMS clients in protected mode as protected mode INT 031h instructions are reflected to real mode.

· There is no API for hooking interrupts in protected mode. You must hook all hardware and software interrupts in real mode, and use call-ups to pass control to a protected mode handler if required.

· Most DPMS calls from real mode are processed by the server in protected mode, and therefore the server must switch modes twice for each call. These mode switches are not required for DPMS calls originating in protected mode. This gives a performance advantage for protected mode over real mode. It is therefore recommended that you make any frequent API calls, such as setting up descriptors, from protected mode wherever possible.