Abstract

Since the introduction of Borland Pascal, it is capable to create protected
mode applications for DOS that run under a DPMI host. Either an existing DPMI
host (e.g. Windows) is used; if none is found at startup, an integrated DPMI
host takes over and manages the coexsistence between DOS and the protected
mode application. By browsing the files RTM.EXE and DPMI16BI.OVL, you'll
quickly find that the DOS extender in use is a special version of the common
Ergo DPMI system.
However, this system is far from being perfect. The version of the package
shipped with Borland Pascal (and many versions of Borland C++) is the
"compatible" 286-version of the DOS extender. It can only handle up to 64 MB
of memory (in some cases just 16 MB), has a high interrupt latency and there
are many reported cases in which the initialisation of the DPMI system causes
the computer to reboot. All this makes it inappropriate for modern DOS
applications.
By carefully searching the internet for other versions of the Ergo DPMI
system, we've been able to patch our own version of the DOS extender which is
fully compatible with the old system, but eliminates some of the known bugs.

Existing versions

We've found about 5 different versions of the Ergo DPMI system on the
internet being part of software packages:

(1) Ergo DPMI 1.0 (286)
    (RTM.EXE, RTMRES.EXE, DPMI16BI.OVL, DPMIINST.EXE)
(2) Ergo DPMI 1.1 (286)
    (RTM.EXE, RTMRES.EXE, DPMI16BI.OVL, DPMIINST.EXE)
(3) Ergo DPMI 1.5 (286)
    (RTM.EXE, RTMRES.EXE, DPMI16BI.OVL, DPMIINST.EXE)
(4) Ergo DPMI 1.1 (386/swapping)
    (32RTM.EXE, DPMI32VM.OVL)
(5) Ergo DPMI 1.5 (386/swapping)
    (32RTM.EXE, DPMI32VM.OVL)

Apparently, there are two major groups of versions: old systems that run on
old 286 computers (and therefore can only access 16 MB of RAM if no other
DPMI or VCPI host is present). Newer versions (4) and (5) can run on 386
computers only and provide access to the first 64 MB of RAM, with addition
of paging and swapping.
There don't seem to be any major differences between the 286 versions of
Ergo (1) to (3). However, the versions differ in file size and creation date.
On the other side, (4) and (5) differ in interrupt latency. By benchmarking
the RAM performance with various demons running in the background, it became
obvious that (4) has a very high interrupt latency, even longer than the old
286 versions. This was solved in (5), which provides an even smaller latency
than (1) to (3).

Realtime constraints and hardware specific code

For typical realtime applications, it is vital to have a very low interrupt
latency. Thus, ( cannot be used for such software. Paging, especially in
combination with swapping, can cause other serious problems: hardware
dependent code (such as device drivers and low level routines) and multimedia
software relies on physical memory addresses that are available to hardware
IRQs at any time. The consequence is that this data must reside in locked
memory areas.
All DPMI hosts are advised to implement page locking services. However, there
are several faults that occur when using locked memory:

* The page locking services of the Ergo DPMI system don't seem to work
  properly.
* Locked memory cannot be paged. This can lead to a high amount of external
  memory fragmentation.
* Locked memory cannot be swapped. If virtual memory with swapping is
  enabled, things can get even worse: programs can ask for more locked memory
  than physical RAM is available. Allocating a large amount of locked memory
  can leave only a small number of pages ready for swapping, thus causing
  harddisk thrashing.

Ergo DPMI 386/realtime

Because of the low interrupt latency, we chose (5) as a basis for our new
DPMI host. It seemed necessary to disable swapping in a reliable way. As a
side effect, paging would not happen if there was no swapping. With Borland
Pascal, there are two known ways of enabling swapping within the DPMI host:

1: Call of external procedures in the module RTM:
     procedure InitSwapping; external 'RTM' index 35;
     procedure DoneSwapping; external 'RTM' index 36;
2: By setting the DOS environment variable DPMI32:
     SET DPMI32=SWAPFILE C:\386SPART.PAR

Method one can easily be avoided by simply not calling those external
procedures. It was a hussle to stop method two, since it is controlled by the
user. However, by patching the file DPMI32VM.OVL, the identifiers "DPMIMEM",
"DPMI32" and "SWAPFILE" were simply overwritten with blanks, causing the DPMI
host to ignore all environment variables.

Integration of the new host

Using the new DPMI host with your software is very simple. It is possible to
rename DPMI32VM.OVL to DPMI16BI.OVL and use it with your old loader. However,
we provide a compressed version of RTM.EXE with this package that has been
modified to suit the new overlay. One important note: never use these files
with any version of DESKWORK.

Testing the new host

Of course, it was mandatory to carefully test the behaviour of the new DPMI
host. It proved most reliable, with one exception: it requires an external
A20 routine to enable high memory, as provided by HIMEM.SYS. If this is not
the case, the overlay will halt with DPMI error 4015.
We were amazed to find that this is only true for DOS based machines, though.
The solution to this mystery is the fact that the Windows95 kernel provides
an A20 routine itself, so HIMEM.SYS is obsolete on modern Windows machines.
However, it is essential under pure DOS.

In fact, the loader which is run by MS-DOS (the real-mode program at the
beginning of the .EXE) is what is called a stub. It first tries to use an
existing DPMI host, and records the result. Then it tries to use Borland
RTM services (using a dedicated interrupt, int 2F/AX=$FB42/BX=$1001),
and again records the result. Then it goes TSR, and:
- if the DPMI was not found, it loads DPMI16BI.OVL as an overlay;
 this is taken as enabling an DPMI host
- if the RTM services was not found, it loads RTM.EXE (which is a one-shot
 TSR that exits itself on completion of the program)
- finally, it uses RTM services to load and run itself; RTM services are
 able to use the protected-mode part of a .EXE instead of the real-mode.

The DPMI host can be of two variations:
- a '286-like, that makes use '286 protected mode structure; DOSX.EXE (aka
    Windows 3.x standard mode) and DPMI16BI.OVL are examples
- a '386-like, that makes use '386 structures; Windows WIN386.EXE enhanced
    mode, Win9X, Go32, DPMI32VM.OVL, etc., are examples; it is by far the
    most common these days
One should add that so-called '286 DPMI host are in fact (except for the
oldest versions, before 1988) aware of what a 386 is, and reacts
accordingly (for example by using more than 16 MB of memory if available).

The DOS extenders also come in two variations:
- 16-bit extenders, like Ergo OS/286, RTM.EXE, or Windows 3.x (yes, even
    in enhanced mode!)
- 32-bit extenders, like Ergo OS/386, 32RTM.EXE, or Win32

Thanks to DPMI specifications, whether you use the former or the latter
category of DPMI host is immaterial to the extender (so you can run Borland
DPMI programs in Windows).

On the other hand, either your program is compiled for the former kind
of extender (so it is called a 16-bit program), or for the latter (and
we call it 32-bit).
There is no way to pass from one to the other short to rebuild all
with different tools.

I assume the following talks about the Ergo 286 DPMI host

I am aware of two versions of the 286 host, both of them copyrighted Ergo:
- version 8232 (build 1992-10-21 17:14:00), which shipped with BP7/TP7
- and version 5032 (depending of the package, build 1993-11-16 19:10:22,
1994-05-25 17:56:23 or 1994-07-18 17:53:20), which shipped with BC4+ and
Delphi 1, and available at Borland ftp site.
I do not know what shipped with BC++ 2.0 and 3.x (information welcome;
I am almost sure that a precedent version [BC2] was not able to correctly
handle the 386).

I am also aware of only one version of the 386 host with VM support :
version 5032 (built either 1993-11-16 19:10:22 or 1994-07-18 17:53:36),
which shipped with BC4+. However, your tests show there are differences
between the builds (probably a bug with the original one).

While there are references to a 386 host without VM (DPMI32BI.OVL), I never
encountered it. DPMIINST.EXE is a support program for the Ergo 286 host.

On the other hand they are the DOS extenders:
* The 16-bit DOS extender (RTM.EXE) comes in 3 versions (not counting its
  predecessors, DPMILOAD.EXE and DPMIMEM.DLL):
 - version 1.0 shipped with BP7/TP7 and was 84 KB in length
 - version 1.1 shipped with BC4 and was 107 KB in length
 - version 1.5 shipped with BC4.02+ and Delphi, and was 119 KB in length.

* The 32-bit DOS extender (32RTM.EXE) comes (at least) in 2 versions:
 - version 1.0 shipped with BC4 and was 139 KB in length
 - version 1.5 shipped with BC5 and was 149 KB in length.

On the other hand, even if your DPMI host is able to provide more,
RTM.EXE does not seem able to manage more than 64 MB (probably
another 16-bit counter somewhere, related with the parsing of
EXTMAX in the environment string RTM...)

Do you want to say that you have been able to run a program compiled
with BP7 with *only* the files mentionned under (4) or (5) ?

By the way, interrupt latency comes from the DPMI host (so DPMI32VM.OVL,
but it can be replaced by anyone you like, however note that Windows will
take over).

You should then consider using other DPMI hosts than Ergo. PMODE (various
versions are available) might be a very good choice for your problem, since
it does not implement paging and is optimized toward speed.  It is freely
available on the net, both as binary or C source.

Hope it helps,

--
Marco van de Voort (Mar...@stack.nl)

Can you gives us any specifics about "paging and locking not working
properly".

TIA

--
Jay

Here I am perfectly able to allocate 62 MB with clean boot
(Dell G1, i.e. "old" Phoenix BIOS, with 128 MB main RAM memory).
I should test better, but it was my impression that when clean-booted,
DPMI16BI.OVL takes over every memory using int 15 AH=88, and
certainly this interface is supposed to give access to 63 MB when
such memory is installed.

I usually prefer HIMEM.SYS over "clean boot", since it does a better
job at managing the A20 line than most extended mode program, and
does a reasonnable job at managing extended memory, without
costing too much: around 1200 bytes in core memory, which are more
than compensated with DOS in HMA, and an additional 4500 bytes in HMA.

Problem : the counter is 16-bit, so 65535 KB is a maximum.

OTOH, it is quite true that the original AT BIOS and the XMS version 2
both have a problem to go beyond 64 MB (for exactely the same reason,
by the way: interface are 16-bits). So to go beyond 64 MB, you better
use a XMS driver version 3, which knows of the more recent BIOS interfaces
(int 15,AX=E8xx) that "know" about >64 MB main memory. Then even old tools
like Ergo DPMI hosts or DOSX.EXE (and probably DOS/4G) can made use of
this memory, *if* they are able to count it! (which as I said is not the
case for DPMI16BI.OVL).

Well, as I said, here I got 62 MB (certainly no EMM396.EXE, and no
HIMEM.SYS either on this try; including HIMEM.SYS gives me 63,8 MB).

You cannot run a 16-bit BP7 -CP compiled program without RTM.EXE.
And renaming 32RTM.EXE as RTM.EXE won't help.

That was my point, from the beginning (distinguishing DPMI host
and extenders).