Fix for CauseWay DOS extender under DR-DOS 7.0x EMM386.EXE
Matthias Paul
Dear CauseWay and DR-DOS 7 users,
This is just to inform those who develop or use DOS applications
which make use of Devore Software´s CauseWay DOS extender, that
older issues of this extender (before 3.34???) can cause crashes
at application startup or exit time under the EMM386.EXE 3.00-3.27
memory managers shipping with Novell DOS 7, OpenDOS 7.01, and
DR-DOS 7.02-7.05, and that it appears to be possible to fix
these problems simply by upgrading the application to use the
latest issue of the CauseWay extender as described below.
Not all, but some other problems can at least be worked around with
special configuration settings of the extender and memory manager,
which might be useful to mention in the user documentation of those
applications.
It is my observation, that many 3rd party applications currently
distributed are still linked to rather old and long out-dated
issues of the CauseWay extender, unfortunately, most probably not
because newer issues won´t work, but just because the applications
have only been tested with MS-DOS/PC DOS EMM386.EXE loaded, so
that the problems in conjunction with DR-DOS EMM386.EXE never
showed during in-house testing.
Since Devore Software has been so generous to release the CauseWay
binaries and sources into the Public Domain in 2000-01, I would
like to suggest that you upgrade your development environment to
the latest issue of the extender, CauseWay 3.49. This should have
no impact for other DOS platforms and configurations, in fact,
it may even fix a few problems with them as well. CauseWay is
freely available from Devore Software´s web site at:
http://www.devoresoftware.com/freesource/cwsrc.htm.
For testing, OpenDOS 7.01, DR-DOS 7.02, and DR-DOS 7.03 binary
distributions are available for download from Lineo´s FTP-Server at:
(DR-DOS 7.02/7.03 includes LOADER which allows multi-boot installations
to co-exist with other operating systems such as MS-DOS/PC DOS, Windows,
etc. This makes setting up a test environment very easy, as long
as a (shareable) primary FAT16 boot partition exist. Questions
regarding DR-DOS can be best directed into the DR-DOS mailing list
<ope...@delorie.com> (subscription at http://www.delorie.com) or may
be covered already at http://www.drdos.org or http://www.drdos.net.)
In case the original development environment and build tools are no
longer set up to apply the proposed change easily, it is also possible
to just re-stub the already existing application binaries simply by
using Devore Software's tool CW349.EXE (which is part of the binary
CauseWay package mentioned above) as follows:
CW349.EXE b- u+ yourapp.exe
This method can also be performed in the field. Even normal end-users
can try this method, if they experience crashes of applications using
this extender under DR-DOS EMM386.EXE. One easy method to find out,
if the application in question is actually using CauseWay, is to issue
FIND "CauseWay" yourapp.exe
at the DOS prompt. CauseWay applications contain a signature similar to:
"CauseWay DOS Extender v3.49 Copyright 1992-99 Michael Devore."
Personally, I am aware of only a hand-full of applications using
this extender, but there are probably tons of them out there and
CauseWay is one of the proposed default DOS extenders for Open Watcom
(http://www.scitechsoft.com). For most of those where I have tried
the upgrade procedure described above, this either fixed all
problems with the DR-DOS EMM386.EXE memory manager or at least
I have user reports which make me believe it did. In none of the
cases it had any inadvertent effects.
For a small survey, I would like to ask you to drop me a short note,
if you are aware of applications using this extender (in particular
if they are using older issues of CauseWay), so that I can try to
locate the developers and make them aware of the problem, so that
they can upgrade their distributions. If you happen to run DR-DOS
as well, please try the hot-fix yourself and tell me if it worked
for you. Ideally, inform the corresponding application vendor yourself,
and feel free to forward this post to them if you like.
Here are a few more observations from my tests:
The problems occur only when using the DR-DOS EMM386.EXE 3.00 (from 1992)
- 3.27 (current public issue), not with the older DR DOS 6.0 EMM386.EXE
2.xx, not when the MS-DOS/PC DOS EMM386.EXE is used (which, however,
supports only a fraction of the features of the DR-DOS counterpart),
and also not, when only HIMEM.SYS of either brand is loaded.
For older issues of CauseWay the problems appear to be independent
of otherwise crucial EMM386.EXE configuration options like /DPMI or
/MULTI, and also occur under MS-DOS/PC DOS, when the DR-DOS EMM386.EXE
is loaded there.
The crashes (usually with EMM386 register dump) occur either at startup
or exit of the application. Sometimes it was possible to recover from
the situation, sometimes the system was stoned (sometimes with a
black screen) and required a reboot. During my tests, any of these
startup or exit problems vanished after upgrading to CauseWay 3.49.
Since the problems could be fixed this way, I have not gone into
the trouble to track them down at program level yet.
I have also observed other unrelated problems which appear to depend
on how hardware interrupts are handled under DR-DOS´ EMM386.EXE 3.xx:
In one particular example of LSI Logic/SymBIOS-based DOS SCSI tools
like INSTALL.EXE, SYMCONF.EXE/CONFIG.EXE (4.03/4.05), SYMDIAG.EXE
(4.03/4.05), and ASPIFMT.EXE (http://www.lsilogic.com: DOS4xx.ZIP,
including OEM file issues like those from Asus, Nomai, etc.) the
previously observed startup/exit crashes were fixed by simply
restubbing with the latest issue of CauseWay, but the applications
kept crashing when keys were pressed on the keyboard or the mouse
was moved, or the applications just could not find any SCSI devices
when querying the system for SCSI peripherals (SYMCONF/CONFIG),
and often hung when scanning the system (SYMDIAG).
The specifically observed behaviour of these applications depended
on the memory manager and DOS extender configuration:
If CauseWay was forced to use VCPI (because DPMI was not loaded with
EMM386.EXE /DPMI, or it was temporarily disabled with "DPMI.EXE off"
at the prompt (see INT 2Fh/AX=1687h below), or the reserved environment
variable CAUSEWAY=DPMI was not set) *and* the DR-DOS EMM386.EXE was
configured to EMM386.EXE /PIC=ON, all these applications ran without
problems, even under the DR-DOS multitasker...
The EMM386.EXE /PIC=ON setting will report to VCPI applications that
the Programmable Interrupt Controller (PIC) is *not* revectored,
although it still is. The default is to leave this disabled as PIC=OFF,
so that it will report the true state (see INT 67h/AX=DE0Ah below).
If, however, CauseWay was forced to use DPMI instead of VCPI by
setting CAUSEWAY=DPMI or CAUSEWAY=DPMI;NOEX *and* loading a DPMI
server (EMM386 /DPMI and "DPMI.EXE on", or loading CWSDPMI r4),
the EMM386.EXE /PIC=ON|OFF setting had no effect and the behaviour
of the application depended on the used DPMI server:
Using DR-DOS´ own DPMI server, the keyboard and mouse functions
were fine, but no SCSI peripherals were found by the tools.
Using CWIDPMI instead, the keyboard was fine and SCSI devices
were found during the scan, but the system crashed with an
EMM386 register dump as soon as the mouse was moved.
I am mentioning this example, because I assume, that other CauseWay
applications using hardware interrupts may show a similar behaviour
under DR-DOS EMM386.EXE.
Fortunately, at least the VCPI + EMM386 /PIC=ON setting seems
to allow to use these applications without problems (after the
CauseWay upgrade), at least in those cases which I have tested.
It would certainly be interesting for me to learn, if this also
works for others.
One more observation:
So far all applications using the CauseWay extender I have tested
were temporarily suspended when switched into background under
the DR-DOS pre-emptive multitasker (EMM386.EXE /MULTI + TASKMGR),
even if the reserved CAUSEWAY environment variable was set to
DPMI (SET CAUSEWAY=DPMI or SET CAUSEWAY=DPMI;NOEX), although
true DPMI applications should normally continue to run in
background, and the very same applications continue to run in
background for example under Windows 98 SE. I have not examined
yet why this is, however, it is only a remaining limitation,
not really a serious problem - although it can be annoying
at times: For example Frisk´s famous DOS virus-scanner F-PROT
(http://www.complex.is), which utilizes CauseWay, would otherwise
be an ideal candidate for background scanning under DR-DOS...
At least, it /functions/ without problems under DR-DOS EMM386.EXE...
Well, I hope this report can help those, who have experienced
similar problems under DR-DOS, as well as those, who develop
applications using the CauseWay extender to improve their support
for DR-DOS EMM386.EXE.
I wished I would know of a perfect solution to make it work in all
configuration settings either by fixing DR-DOS EMM386.EXE or CauseWay,
but that won´t help in existing installations, anyway.
Would the "DPMI.EXE OFF" + "EMM386.EXE /PIC=ON" workaround prove
to be a general solution for a particular application - or more of
them -, it might be possible to special case this either in CauseWay
or the application´s startup code, hence I am attaching some API
info how to temporarily change the DPMI.EXE ON|OFF and EMM386.EXE
PIC=ON|OFF settings in the startup code - however, if this will
be used to change the settings I strongly suggest to add an option
to disable this just in case it would introduce new problems on
some other systems or with future issues of the DR-DOS EMM386.EXE,
which may no longer require the fix, and it is also important that
the old settings always get restored when exiting the application,
otherwise this would certainly generate more new compatiblity
problems than it could possibly solve. So, please let me know
before you´d start using this somewhere...
Anyway, hope it helps and thanks for reading. (A special Thank You
to Joe da Silva, who has made me aware of the problem originally!)
Greetings,
Matthias
Appendix: Switching DR-DOS DPMI on|off and DR-DOS EMM386 PIC=on|off
(This API info should also show up in the next issue of RBIL)
--------------------------------------------------
INT 2F - DOS Protected-Mode Interface - INSTALLATION CHECK
AX = 1687h
(DI = 4320h & SI = 4544h "EDC ", see note)
Return: AX = 0000h if installed
BX = flags
bit 0: 32-bit programs supported
CL = processor type (02h=80286, 03h=80386, 04h=80486)
DH = DPMI major version
DL = two-digit DPMI minor version (binary)
SI = number of paragraphs of DOS extender private data
ES:DI -> DPMI mode-switch entry point (see #02718)
AX nonzero if not installed
Notes: the Novell DOS 7 - DR-DOS 7.03 DPMI.EXE calls this function with
magic values DI = 4320h, SI = 4544h (for unknown purposes),
and on return uses the ES value to locate the segment of the
resident DPMI driver (ES:0). It first checks the DPMI ID "EDC"
in the DR-DOS DPMI header structure (see table below) before
accessing the DPMI status setting in the DR-DOS DPMI instance
data.
(Table 02718)
Call DPMI mode switch entry point with:
AX = flags
bit 0: set if 32-bit program
ES = real mode segment of buffer for DPMI private data
(ignored if SI was zero)
Return: CF set on error
program still in real mode
AX = error code (DPMI 1.0+)
8011h unable to allocate all necessary descriptors
8021h 32-bit program specified, but 16-bit DPMI host
CF clear if successful
CS = 16-bit selector corresponding to real-mode CS
SS = selector corresponding to real-mode SS (64K limit)
DS = selector corresponding to real-mode DS (64K limit)
ES = selector to program's PSP (100h byte limit)
FS = GS = 0
high word of ESP = 0 if 32-bit program
program now in protected mode
Note: this entry point is only called for the initial switch to
protected mode
DR-DOS DPMI header structure:
WORD next offset
WORD next segment
WORD device type
WORD strategy vector
WORD interrupt vector
8 BYTEs driver name
10 BYTEs driver data
3 BYTEs DPMI ID "EDC"
WORD DPMI version
WORD segment of DR-DOS DPMI instance data (see below)
DR-DOS DPMI instance data:
BYTE DPMI status
00h = DPMI is disabled
FFh = DPMI is enabled
Note: running under the DR-DOS multitasker it is possible to
independently control the "DPMI on|off" state on a
task-by-task basis.
--------------------------------------------------
INT 67 - Virtual Control Program Interface - GET 8259 INT VECTOR MAPPINGS
AX = DE0Ah
(BX <> 454Eh "NE", see note)
(CH <> 49h "I", see note)
Return: AH = 00h successful
BX = first vector used by master 8259 (IRQ0)
CX = first vector used by slave 8259 (IRQ8)
AH nonzero: failed
Note: CX is undefined in systems without a slave 8259
BX and CH registers should not match the "NEI" signature because
of the PIC=ON|OFF API of the Novell DOS 7+ EMM386 3.04+ residing
at the same function. If set to PIC=ON, VCPI applications will
be told that the PIC has *not* been revectored (BX = 0008h),
regardless of the true state.
--------------------------------------------------
INT 67 U - Novell DOS 7+ EMM386.EXE 3.04+ VCPI - SET/GET PIC VECTOR STATE
AX = DE0Ah
BX = 454Eh 'NE'
CH = 49h 'I'
CL = PIC mode
bit 7-2 reserved (0)
bits 1-0 =11b reserved
=10b set PIC=ON to report the faked state of
master 8259
=01b set PIC=OFF to report the true state of
master 8259
=00b reserved
Return: AH = 00h successful
(PIC=OFF) BX = true 1st vector used by master 8259 (IRQ0)
(PIC=ON) BX = faked 1st vector used by master 8259 (IRQ0):
0008h
CX = first vector used by slave 8259 (IRQ8)
AH nonzero: failed
Note: CX is undefined in systems without a slave 8259
the Novell DOS 7+ EMM386 3.04+ has a command line option
PIC=ON|OFF. It is still supported by the DR-DOS 7.03 EMM386.EXE
3.27. If set to PIC=ON, VCPI applications will be told that the
PIC has *not* been revectored. With PIC=OFF (default) the true
vector is reported in BX. PIC=ON is intended to fix DOS 4GW
problems and seems to get most of the games working on the single
tasking EMM386, but a couple still fail on the multitasking
EMM386. When using the multitasking EMM386, DPMI may be switched
OFF as well for these games to run. It may also help applications
using the CauseWay DOS extender when using VCPI.
--------------------------------------------------
--
<mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org