The DOS Protected Mode Interface helps you with various aspects of protected
mode programming. These are roughly divided into descriptor handling, access to DOS memory,
management of interrupts and exceptions, calls to real mode functions and other stuff. Additionally
it automatically provides swapping to disk for memory intensive applications. A DPMI
host (either a Windows DOS box or CWSDPMI.EXE) provides these functions for your
programs.
Descriptors are a bit like real mode segments; they describe (as the name
implies) a memory area in protected mode. A descriptor contains information about segment
length, its base address and the attributes of it (i.e. type, access rights, ...). These descriptors are
stored internally in a so-called descriptor table, which is basically an array of such descriptors.
Selectors are roughly an index into this table. Because these ’segments’ can be up to 4 GB in size,
32 bits aren’t sufficient anymore to describe a single memory location like in real mode. 48 bits are
now needed to do this, a 32 bit address and a 16 bit sized selector. The GO32 unit provides
the tseginfo record to store such a pointer. But due to the fact that most of the time
data is stored and accessed in the %ds selector, FPC assumes that all pointers point
to a memory location of this selector. So a single pointer is still only 32 bits in size.
This value represents the offset from the data segment base address to this memory
location.
The %ds and %es selector MUST always contain the same value or some system
routines may crash when called. The %fs selector is preloaded with the DOSMEMSELECTOR
variable at startup, and it MUST be restored after use, because again FPC relys on this for some
functions. Luckily we asm programmers can still use the %gs selector for our own purposes, but for
how long ? See also: get__cs (160), get__ds (161), gett__ss (169), allocate__ldt__descriptors (151),
free__ldt__descriptor (159), segment__to__descriptor (178), get__next__selector__increment__value (163),
get__segment__base__address (168), set__segment__base__address (181), set__segment__limit (181),
create__code__segment__alias__descriptor (154)
DOS memory is accessed by the predefined dosmemselector selector; the GO32
unit additionally provides some functions to help you with standard tasks, like copying memory
from heap to DOS memory and the likes. Because of this it is strongly recommened to use them,
but you are still free to use the provided standard memory accessing functions which use
48 bit pointers. The third, but only thought for compatibility purposes, is using the
mem[]-arrays. These arrays map the whole 1 Mb DOS space. They shouldn’t be used
within new programs. To convert a segment:offset real mode address to a protected
mode linear address you have to multiply the segment by 16 and add its offset. This
linear address can be used in combination with the DOSMEMSELECTOR variable.
See also: dosmemget (157), dosmemput (158), dosmemmove (157), dosmemfillchar (155),
dosmemfillword (156), mem[]-arrays, seg__move (178), seg__fillchar (176), seg__fillword
(177).
The I/O port access is done via the various inportb (172), outportb (174) functions
which are available. Additionally Free Pascal supports the Turbo Pascal PORT[]-arrays but it is by
no means recommened to use them, because they’re only for compatibility purposes. See also:
outportb (174), inportb (172), PORT[]-arrays
These are some functions to access various segment registers (%cs, %ds,
%ss) which makes your work a bit easier. See also: get__cs (160), get__ds (161), get__ss
(169)
Interrupts are program interruption requests, which in one or another way get
to the processor; there’s a distinction between software and hardware interrupts. The former are
explicitely called by an ’int’ instruction and are a bit comparable to normal functions. Hardware
interrupts come from external devices like the keyboard or mouse. Functions that handle hardware
interrupts are called handlers.
The interrupt functions are real-mode procedures; they normally
can’t be called in protected mode without the risk of an protection fault. So the DPMI host creates
an interrupt descriptor table for the application. Initially all software interrupts (except for int 31h,
2Fh and 21h function 4Ch) or external hardware interrupts are simply directed to a handler that
reflects the interrupt in real-mode, i.e. the DPMI host’s default handlers switch the CPU to
real-mode, issue the interrupt and switch back to protected mode. The contents of general registers
and flags are passed to the real mode handler and the modified registers and flags are returned to
the protected mode handler. Segment registers and stack pointer are not passed between
modes.
As mentioned before, there’s a distinction
between real mode interrupts and protected mode interrupts; the latter are protected mode
programs, while the former must be real mode programs. To call a protected mode interrupt
handler, an assembly ’int’ call must be issued, while the other is called via the realintr() or intr()
function. Consequently, a real mode interrupt then must either reside in DOS memory (¡1MB) or
the application must allocate a real mode callback address via the get__rm__callback()
function.
Interrupt redirection with FPC pascal is done via the
set__pm__interrupt() for protected mode interrupts or via the set__rm__interrupt() for real mode
interrupts.
The GO32 unit provides the two procedures disable() and enable() to disable
and enable all interrupts.
Hardware interrupts are generated by hardware devices when something
unusual happens; this could be a keypress or a mouse move or any other action. This is done
to minimize CPU time, else the CPU would have to check all installed hardware for
data in a big loop (this method is called ’polling’) and this would take much time. A
standard IBM-PC has two interrupt controllers, that are responsible for these hardware
interrupts: both allow up to 8 different interrupt sources (IRQs, interrupt requests). The
second controller is connected to the first through IRQ 2 for compatibility reasons, e.g. if
controller 1 gets an IRQ 2, he hands the IRQ over to controller 2. Because of this up
to 15 different hardware interrupt sources can be handled. IRQ 0 through IRQ 7 are
mapped to interrupts 8h to Fh and the second controller (IRQ 8 to 15) is mapped to
interrupt 70h to 77h. All of the code and data touched by these handlers MUST be
locked (via the various locking functions) to avoid page faults at interrupt time. Because
hardware interrupts are called (as in real mode) with interrupts disabled, the handler has to
enable them before it returns to normal program execution. Additionally a hardware
interrupt must send an EOI (end of interrupt) command to the responsible controller; this
is acomplished by sending the value 20h to port 20h (for the first controller) or A0h
(for the second controller). The following example shows how to redirect the keyboard
interrupt.
Listing: go32ex/keyclick.pp
Ordinarily, a handler installed with set__pm__interrupt (179) only services
software interrupts that are executed in protected mode; real mode software interrupts can be
redirected by set__rm__interrupt (181). See also set__rm__interrupt (181), get__rm__interrupt (167),
set__pm__interrupt (179), get__pm__interrupt (163), lock__data (173), lock__code (173), enable (158),
disable (155), outportb (174) Executing software interrupts Simply execute a realintr() call with the
desired interrupt number and the supplied register data structure. But some of these
interrupts require you to supply them a pointer to a buffer where they can store data to or
obtain data from in memory. These interrupts are real mode functions and so they
only can access the first Mb of linear address space, not FPC’s data segment. For this
reason FPC supplies a pre-initialized DOS memory location within the GO32 unit. This
buffer is internally used for DOS functions too and so it’s contents may change when
calling other procedures. It’s size can be obtained with tb__size (182) and it’s linear
address via transfer__buffer (182). Another way is to allocate a completely new DOS
memory area via the global__dos__alloc (169) function for your use and supply its real
mode address. See also: tb__size (182), transfer__buffer (182). global__dos__alloc (169),
global__dos__free (171), realintr (175) The following examples illustrate the use of software
interrupts.
Listing: go32ex/softint.pp
Listing: go32ex/rmpmint.pp
The callback mechanism can be thought of as the converse of calling a real
mode procedure (i.e. interrupt), which allows your program to pass information to a real
mode program, or obtain services from it in a manner that’s transparent to the real
mode program. In order to make a real mode callback available, you must first get the
real mode callback address of your procedure and the selector and offset of a register
data structure. This real mode callback address (this is a segment:offset address) can
be passed to a real mode program via a software interrupt, a DOS memory block or
any other convenient mechanism. When the real mode program calls the callback (via
a far call), the DPMI host saves the registers contents in the supplied register data
structure, switches into protected mode, and enters the callback routine with the following
settings:
- interrupts disabled
- %CS:%EIP = 48 bit pointer specified in the original call to get__rm__callback (164)
- %DS:%ESI = 48 bit pointer to to real mode SS:SP
- %ES:%EDI = 48 bit pointer of real mode register data structure.
- %SS:%ESP = locked protected mode stack
- All other registers undefined
The callback procedure can then extract its parameters from the real mode register data structure
and/or copy parameters from the real mode stack to the protected mode stack. Recall that the
segment register fields of the real mode register data structure contain segment or paragraph
addresses that are not valid in protected mode. Far pointers passed in the real mode register data
structure must be translated to virtual addresses before they can be used with a protected mode
program. The callback procedure exits by executing an IRET with the address of the real mode
register data structure in %ES:%EDI, passing information back to the real mode caller by
modifying the contents of the real mode register data structure and/or manipulating
the contents of the real mode stack. The callback procedure is responsible for setting
the proper address for resumption of real mode execution into the real mode register
data structure; typically, this is accomplished by extracting the return address from the
real mode stack and placing it into the %CS:%EIP fields of the real mode register data
structure. After the IRET, the DPMI host switches the CPU back into real mode, loads
ALL registers with the contents of the real mode register data structure, and finally
returns control to the real mode program. All variables and code touched by the callback
procedure MUST be locked to prevent page faults. See also: get__rm__callback (164),
free__rm__callback (160), lock__code (173), lock__data (173)