X-Authentication-Warning: delorie.com: mail set sender to opendos-bounces using -f Date: Thu, 17 Jun 2004 09:59:41 +0200 From: Matthias Paul Subject: Re: Random Lockups with DR-DOS 7.03 To: opendos AT delorie DOT com Message-id: <001601c45445$7e320360$c03dfea9@atlantis> Organization: Aachen University of Technology (RWTH), Germany MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200406100759 DOT i5A7xXRK010329 AT delorie DOT com> Reply-To: opendos AT delorie DOT com On 2004-06-16, Paul O. Bartlett wrote: > However, if anyone thinks that it would be better dealt with offline > by individual email, that is fine with me. You are welcome to discuss your DR-DOS setup and post your configuration files here. After all the whole purpose of this mailing list is to share experiences and build a knowledge pool among the DR-DOS users. And for the former developers of the operating system, of whom at least some still read this forum, it is always interesting to learn about real-world problems. And as much as time allows we may even be able to help end users by giving hints on less widely known configuration options. In some cases, if problems would turn out to follow a systematic pattern, solutions found here may even lead into feature enhancements in possible future issues of DR-DOS - at least potentially... >>> [...] When I boot into DR-DOS the first message that comes up >>> is "Hard disk 2 configuration error," but I presume this is an >>> artefact of Win98 mucking around with things. The D: partition >>> seems to be fully usable from DR-DOS. >> [...] > This message appears after "Starting Caldera DR-DOS..." and before > the first message from EMM386.EXE, which is the first thing that loads > in CONFIG.SYS. The common partition gets IMAGEd by the Norton > Utilities for Windows running when I have booted into Win98. From > DR-DOS I cannot delete (even after resetting the file attributes) > IMAGE.DAT and IMAGE.IDX in the root of the D: partition, so I presume > that Win does some kind of funny stuff that is disliked by something > on the DR-DOS side of the fence. Normally (that is, under MS-DOS/PC DOS), CONFIG.SYS directives get reordered into certain groups before they take effect. Thus, the order of directives in CONFIG.SYS does not necessarily reflect the actual load order of drivers. Under DR-DOS, CONFIG.SYS does not get compiled but interpreted, so directives are executed as the parser runs through the file (with the sole exception of SWITCHES= and SHELL=/HISHELL=/SHELLHIGH=). Some settings are just recorded to take effect at a later stage in the boot process, but drivers (loaded by DEVICE=/HIDEVICE=/ DEVICEHIGH=) and TSRs (loaded by INSTALL=/HIINSTALL=/INSTALLHIGH=) will be loaded immediately and in exactly that order and will not become reordered. However, even if EMM386 is the first driver you load in CONFIG.SYS, before DR-DOS tries to execute CONFIG.SYS it will first try to find a file named DCONFIG.SYS. In case DCONFIG.SYS exists, this will override CONFIG.SYS (so you could have different configuration files for Windows 98 and DR-DOS). (Some issues also support either ODCONFIG.SYS or DRCONFIG.SYS.) However, DR-DOS also supports a special CONFIG.SYS directive named CHAIN=secondary_config_sys_file,label Assuming you would have a DCONFIG.SYS file like: DEVICE=unknown.sys [assumed to issue message: "Harddisk 2 configuration error"] CHAIN=config.sys you could easily be fooled into thinking that DR-DOS would execute CONFIG.SYS (without any driver loaded before EMM386.EXE), while it would actually execute DCONFIG.SYS (and thereby load UNKNOWN.SYS) and only then chain into CONFIG.SYS. (You will be able to track down such issues in F7 or F8 single-stepping mode.) Another possible scenario: In addition to the above said, DR-DOS will try to load drivers via the so called preload API. This happens even before it will attempt to execute *any* kind of CONFIG.SYS file, and as a matter of the fact of how the preload API is supposed to work, it does not require *any* visible settings in any of the CONFIG.SYS files. So, if you have a (possibly) hidden file named SECURITY.BIN, STACKER.BIN, DBLSPACE.BIN or DRVSPACE.BIN in the root of your (DR-DOS visible) drive C: (or in some cases A:), DR-DOS will try to load and communicate with it. These files will exist if you have installed DR-DOS system security or a disk compression such as Stacker, DoubleSpace or DriveSpace. But sometimes (in particular if you use multiple operating systems) they can exist even if you have not installed one of these components. In the latter case, even if loaded the drivers won't normally remain resident (as other prerequisites for them to function are not met) and DR-DOS should silently continue to execute [D]CONFIG.SYS. Now, I /assume/ you will find a file named DRVSPACE.BIN in the root of your boot drive. Since you use Windows 98, this would be DrvSpace 3 which uses a slightly different preload API not supported by DR-DOS 7.03. This *could* be the reason for the error message. I /assume/ the message you see is coming from DRVSPACE.BIN but I only have the German version of this file, so I don't know the exact wording of error messages in the English issue. If you are sure, you do not use any disk compression, you could simply rename that file into something not matching one of the above mentioned "magic" filenames and see, if the error message disappears. However, please do not attempt to do this, if you use disk compression as otherwise you will not be able to access your compressed disk volumes afterwards. Alternatively, it may be possible, that some of the Norton Utilities you are using is "hijacking" the preload API in order to make sure it will get loaded even if no CONFIG.SYS file exists. In this case, the file DRVSPACE.BIN or DBLSPACE.BIN may not actually represent some issue of DriveSpace or DoubleSpace, but some (renamed) file from Norton Utilities' origin. I am not currently aware of any such utility, but I certainly don't use every little features they provide myself and think, it's worth looking into this direction. There are a few other possibilities how to load resident software even before DR-DOS loads, but then they would have to support certain tricks (the INT 12h or the "PROTMAN$" method) or RIPL interfaces (such as "RPL" or "RPLOADER") in order to survive the boot phase. In this case, they may be loaded out of the MBR or the boot partition's boot sector. DiskManager type software would fall into this category, and the text of the error message indicate that it's actually coming for such kind of software. In case of a remote network boot, the software may even be loaded by the system BIOS and come from a remote network server, but I guess you would have mentioned it in case you would use such a setup - it's more that I'm mentioning it for completeness. >>> So far so good. However...... When I am working in DR-DOS, I get >>> completely unpredictable lockups when I return to the command >>> prompt. Locked up tight. Ctr-Alt-Del does not work. I have to >>> press the reset button. These lockups are completely >>> unpredictable, and I cannot detect any pattern to them at all. >>> None. >> >> Do these lockups occur only just after exiting NCC, or in other >> situations too? > > The lockups occur entirely randomly, as nearly as I can tell. I > can be doing just about anything, and when I get back to the command > prompt, the system locks up tight. I cannot detect any pattern > whatsoever. As Michal suggested, I too suggest to temporarily remove NCC. Further I suggest to unload Iomega's GUEST and successively replace it by the individual device drivers, because, as the name suggests, GUEST is designed to be loaded only on a temporary basis in order to get access to a ZIP drive on a guest system. If you want permanent access to your ZIP drive as you do, you can (and should) use the set of modular device drivers Iomega provides for this very purpose. Since a multitude of different ZIP drives exists, there is no single set of configuration lines you could just copy & paste. The most variable part is the hardware driver, in my case I have a SCSI ZIP drive, so I don't need to load the parallel port and IDE drivers. As a possible place to start, here's an ZIP drive related excerpt of my DCONFIG.SYS file: REM DEVICEHIGH=c:\sys\zip\dos.551\ASPIPPM1.SYS FILE=NIBBLE.ILM SPEED=10 Country=049 REM DEVICEHIGH=c:\sys\zip\dos.551\ASPIPPM2.SYS FILE=NIBBLE2.ILM SPEED=10 Country=049 REM DEVICEHIGH=c:\sys\zip\dos.551\ASPIIDE.SYS Scan Info Country=049 REM SCSICFG does not stay resident, it just scans the SCSI bus and writes REM a new SCSI.SCF file for use by SCSIDRV.SYS - it must be run only once REM after a configuration change, not on every boot. DEVICE=c:\sys\zip\dos.551\SCSICFG.EXE /L=049 /V REM This one loads resident and requires around 32 KB as DOS XMSUMB block DEVICEHIGH=c:\sys\zip\dos.551\SCSIDRVR.SYS /L=049 You will have to adapt this to your scenario. >> BTW, much of the NCC functionality is now available >> through CONFIG.SYS directives (NUMLOCK=OFF etc.) and DOS MODE >> command (keyboard delay/autorepeat etc.) > > That may well be the case. I haven't explored the capabilities of > DR-DOS's COMMAND.COM to its fullest extent. My main interest in using > an old NDOS was screen color control. (I detest white letters on a > black screen, and I like a VGA overscan border around the screen.) > However, someone who uses DOS exclusively in a business context has > recommended ANSIPLUS for various capabilities. Does anyone else have > any experience with this? ANSIPLUS is a good Shareware product, although I doubt it is still supported (so you may have problems to get the license key). However, I have experienced problems with its IMHO strange way to configure and have found it to be quite a memory hog. (Most of the keyboard related goodies are also supported by K3PLUS and its successor FREEKEYB, Axel C. Frinke and I developed, but in a much more flexible and less memory consuming way. However, still FREEKEYB is basically a keyboard driver and console enhancement, not an ANSI driver, so it does not support color control - so no useful replacement for your particular purpose.) Since you use NANSI instead of the default ANSI console driver, I suggest to replace NANSI by the DR-DOS ANSI.SYS, just to make sure it isn't your ANSI driver which is causing you problems. Mind, that COMMAND.COM does several callouts (to the console driver as well as to disk cacheing software) immediately before it displays the prompt - and if I understood you correctly you reported your system to crash in this very moment. In either case, once you have solved the crash problem and switched back to NDOS instead of COMMAND.COM, I suggest to upgrade to JP Software's 4DOS, because being maintained up until recently it does support current systems in a much better way than the old NDOS did. Also, it provides thousands of feature additions since the NDOS split off. >> It would be a good idea to temporarily remove (rem out) all drivers >> and TSRs and then (if the lockup disappears) enable them one after >> another to see whether there are any confilicts which cause the >> lockups. > > I have taken COUNTRY.SYS more or less permanently out of the > picture. I live in the USA, so I suppose the defaults are adequate. Well, despite its file extension COUNTRY.SYS in particular is no driver at all. ;-) It is a database containing country specific data, and is used in conjunction with CONFIG.SYS COUNTRY= and NLSFUNC. Using COUNTRY= does *not* require any memory at all. No harm to use it. Unless you would have limited disk space (as for example on a boot floppy) I suggest to utilize COUNTRY= even in the US, because the US country settings in COUNTRY.SYS are not the same as the default country settings in DR-DOS itself. > HOWEVER, this afternoon, I took GUEST.EXE, the Iomega ZIPdrive > driver, out of AUTOEXEC.BAT, and for the length of time I was working > I had no lockups. Then I started GUEST.EXE (it can load from the > command line or AUTOEXEC.BAT), and after some time I had another > lockup. That might tend to point to that driver, although further > work will be needed to try to point to that conclusively. Yep. Greetings, Matthias -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org "Programs are poems for computers."