Chip 2000 February/Chip_2000-02_cd.bin/sharewar/pctra/PROBLEMS.TXT

Text File | 1995-07-14 | 4KB | 75 lines

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.