About DPMI Conflicts
--------------------

This application utilizes the DOS Protected Mode Interface (DPMI) 
protocol. This means it runs in Protected mode, which is a CPU mode 
that permits programs to access ALL available extended memory in your 
computer, not just a portion of the 640K conventional memory like 
most of the other programs you may be running. 

While this does give programs access to available extended memory, 
there are some drawbacks due to the way protected mode operation is 
implemented in DOS. Briefly, programs that wish to access extended 
memory in protected mode must provide an auxiliary program, sometimes 
called the DPMI server, to provide this access. This server works 
between DOS and the application to make it work. 

The problem comes with the fact that while there is a protocol 
defined with which to access the memory, DOS provides no standard 
interface program. Each different application running in protected 
mode supplies it's own program to do the interfacing. This works fine 
with DOS when only one program is running at a time, but causes great 
big problems when conflicting DPMI servers are trying to access the 
same memory at the same time. This occurs when programs are installed 
as Terminate and Stay Resident programs (TSR's). These programs 
remain in memory, running in the background. When another program 
loads it's own DPMI server to run, it conflicts with the one running 
in memory, causing the computer to crash with strange effects, or to 
totally reboot. 

As described above, this application requires the use of a DPMI 
server, and one is supplied to do this. If you have other 
applications that use a DPMI server that remain running in the 
background, this application will most likely come to an abrupt and 
ungraceful halt. This is not the fault of either application, it is 
simply the result of two applications running and accessing the same 
memory at the same time in an operating system that was not designed 
to operate in such a way. Unfortunately, many popular memory managers 
and disk compression programs utilize DPMI servers that remain 
resident, and cause conflict with other applications. Some programs 
that are known to cause such problems are various memory management 
programs such as CEMM, QEMM, EMM386 and 386MAX. Some disk compression 
programs, such as Stacker have also caused conflicts. Other instances 
of conflicts have been caused by some off-brand mouse drivers.  

If you are having problems running this application, with such 
symptoms as: the application exiting to DOS in the middle of 
operation; rebooting; getting "Unhandled Exception Error..." 
messages; exiting to DOS and then finding less than 100K memory being 
reported by the mem command; then you have a memory conflict. The 
only solution is to remove one of the conflicting applications, 
either this one, or the memory resident application. Some of these 
are loaded in your CONFIG.SYS file or your AUTOEXEC.BAT file. They 
can  be removed by commenting them out by placing a REM statement at 
the beginning of the line. Others, such as disk compression software, 
will not be so easy, since without the software running, you will not 
have access to your drive contents. 

Known incompatibilities:
------------------------

ULSI Coprocessor

There have been some reports of problems that have been traced to the
use of a ULSI math coprocessor. The problems typically appear in 
graphics track, with an Unhandled Exception error occuring. This
appears to be a problem with the coprocessor, and has been remedied
in every instance by replacing the coprocessor with an Intel
chip. There have been no reported problems with any other brand
of coprocessor.

Microsoft Mouse driver 9.01

There have been reports of incompatibilites with Microsoft Mouse 
driver version 9.01. No details were reported.