X-Authentication-Warning: delorie.com: mailnull set sender to opendos-bounces using -f Message-ID: <000301c1956f$747026a0$c03dfea9@atlantis> From: "Matthias Paul" To: Cc: , Subject: Fix for CauseWay DOS extender under DR-DOS 7.0x EMM386.EXE Date: Fri, 4 Jan 2002 23:25:44 +0100 Organization: University of Technology, RWTH Aachen, Germany MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g04MUDR28929 Reply-To: opendos AT delorie DOT com [FYI: From a discussion in comp.os.msdos.programmer. We have already dealt with this problem in our forum here, but I´m not sure if I described the issue in better details.] 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: ftp://ftp.lineo.com. (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 (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. -------------------------------------------------- -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org