A History of the EMS Page frame.

The EMS page frame was a wonderful thing in 1985 when it was
invented.  Back then the 286 was only just coming on to the
scene and the only way to access more memory was using a
technique called paging, dating back to CP/M and Z80
systems.  So Lotus, Intel, and Microsoft got together and
created a paging specification for Intel 8x86 based PCs.
This was known as the LIM EMS specification.

Paging involves using a small region of memory which in the
LIM EMS is called the EMS page frame.  This small region is
a Window on a much larger pool of memory which can be
accessed by making parts of the large pool available within
the page frame, one part at a time.  This technique worked
well for what it was designed for, and allowed Lotus users
to create much larger spreadsheets.

Later Borland and AST joined the fray and created an
extension to the specification, known as EEMS.  This
extension provided more flexibility and was eventually
rolled into LIM EMS as version 4.0 of the LIM EMS spec.

That was then.....

Today the prevailing CPU is the 386 which can address
directly up to 4Gb.  Today, Paging is not even associated
with EMS, but rather with virtual memory.  And the only
programs still using EMS are those that haven't been updated
in several years, or are designed to be used in an 8088 XT
environment.

All newer programs, including WordPerfect 6.0, MS Word 6,
Lotus 3, Paradox, Foxpro, MS and Borland Compilers, and so
on, are written to use DOS extenders.  DOS extender
technology allows programs to access extra memory directly
on 286 and above systems.  This means that no page switching
has to take place, and programs can create large and complex
data structures which are not possible in a straight 640K
environment even with EMS.

These programs are also easier to engineer because the
actual program code can be larger than 640K.  So DOS
extended programs run faster and can be more complex with
less likelihood of bugs.  Which is exactly why Lotus
Microsoft and Borland, all pioneers and developers of the
EMS specification, have switched to DOS Extenders.

Device drivers and TSRs and EMS

Some drivers and TSRs can make use of EMS to place buffers
and other data in EMS, using the page frame.  There are two
problems with this approach:  Performance, and reliability.

By placing buffers in EMS the programs must first access the
EMS memory manager to switch their buffers into memory so
that they can access them.  This is the root of both
problems.  The switching process is slow as TSRs must issue
several EMS calls in order to access their data.  These
calls MUST be issued each time any access is made to the EMS
stored data, slowing down the driver or TSR.

The second problem is indirectly caused by this same issue.
Drivers that require access to data during interrupt
processing (most drivers do) frequently have to keep
interrupts disabled while they issue the EMS calls.  This
leads to lost interrupts and data overruns because several
interrupts come in during the time that the interrupts are
disabled, and are lost because they could not be processed
in time.

Also, if several drivers are using EMS at the same time
conflicts can arise, particularly in the presence of
background multi-processing TSRs like PC-Kwik and NCACHE, or
Windows.  Code running in the EMS page frame (like EMSNETX)
can get overwritten, and I/O must frequently be redirected
if it is destined for the page frame, causing even more
latency.

A common example of this is lost key strokes or "stuck"
shift keys when several of these kinds of TSRs are loaded.
Unfortunately, this problem is so common that we've put
several features directly into the memory manager to help
programs deal with this problem.  This is part of why
Microsoft abandoned the approach, which they tried in DOS 4,
of placing Disk BUFFERS in EMS.

Drivers and TSRs are better off with the extra memory.

If you use drivers that make use of EMS you are usually
better off letting these drivers place their buffers in
upper memory, and turning off the Page Frame.  Take the case
of MSCDEX and STACKER, both of which can place their buffers
in EMS.  The buffers generally occupy 5 to 20K for MSCDEX
and 20 to 30K for STACKER.  If you disable EMS you'll end up
with 14 to 39K of extra upper memory and both programs will
perform MUCH faster.

Even Games which use EMS can generally be made to run faster
by simply copying the entire game onto a RAM disk, and
making XMS available.

Cloaking vs EMS Stealthing performance.

This is also why we created Cloaking.  Cloaking is a method
of creating upper memory by providing the equivalent of a
DOS extender for the BIOS.  Using our Cloaking drivers the
BIOS and other drivers and TSRs can run directly in extended
memory like DOS extended programs.

We chose this approach because of its unlimited potential,
and unequaled performance.  The simplest EMS call requires
TWO protected mode transitions and a flushing of all the
CPUs look up tables.  In our measurements the fastest EMS
call is 40 times slower than a V86 to protected mode
transition.  So we decided against trying Stealth's approach
of mapping the BIOS into EMS, and developed Cloaking.

EMS and Windows

Finally, Windows applications do not make any use of EMS, in
fact Windows does not provide any EMS emulation to Windows
apps even if EMS was available in the system.  So if you use
Windows, EMS is basically a drag.  Windows has to load an
extra VxD to handle EMS, and has to reserve memory and
resources for EMS each time a DOS VM starts up.  So having
EMS available slows down Windows DOS apps even if they don't
use it.

In Conclusion

Unless you use Lotus 2.2 or Wordperfect 5.1 regularly, you
should seriously consider disabling your EMS in favor of
more upper memory.  (see our note on conventional vs total
memory for info how Windows benefits from upper memory).

Copyright (c) 1993, Helix Software Co.