Mail Archives: opendos/2004/06/17/07:47:11
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
--
<mailto:Matthias DOT Paul AT post DOT rwth-aachen DOT de>; <mailto:mpaul AT drdos DOT org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
"Programs are poems for computers."
- Raw text -