Mail Archives: opendos/1997/06/27/14:06:48
On Fri, 27 Jun 1997, Marek Habersack wrote:
> > Subst can never be loaded from the config.sys, only from the
> > autoexec.bat.
> Why is that? I used subst from config.sys from under DOSemu+M$-FOG
> 6.22 quite successfully.
Yep. And you can do that under OpenDOS, too (though - as I read
from your former reply - the assignments might be reseted after
CONFIG.SYS. I have not tested this myself, since in CONFIG.SYS
I ever have used SUBST only on a temporary basis, e.g. in conjunction
with SETENV to save as much as possible bytes from the environment,
when loading TSRs).
> > If there was confusion from what I posted I am sorry but if subst
> > works on any driver letter from "d" to "z" then nwcdex should
> > also work.
> Well, yes.
Hmm, of course, it was really great, if this could work. But
internally there is a great difference between an utility like SUBST,
modifying CDS attributes, an NWCDEX, which is a redirector. However,
this has also been a problem with MS-DOS/PC-DOS in many scenarios
(not all). Not all, because, if you only have a few hard disk
partitions in your system, the startup default size of the pre-CDS
array might be big enough to hold your new drive letter(s).
Additional slots are added on demand during CONFIG.SYS, that is, when
loading a block device driver. Under all versions of DR DOS, there
has been a pre-CDS array sized 32 (with 3.41) or 26 entries (with
5.0/6.0), but the actual layout was very different between these
three, and completely different from MS-DOS'. Remember, DR DOS prior
to DR DOS 6.0 "business update 1993" did not have a genuine CDS,
instead the internal handling was quite more flexible based on
clusters, allowing for several additional features like directory
paths longer that 67 chars, and something like a "directory-history".
Novell DOS came with a genuine (<- for MS-DOS compatibility)
pre-initialized pre-CDS array of 26 entries, thus it looks as if it
could provide all to solve these problems with NWCDEX etc. once and
for ever. However, DR DOS, Novell DOS, and OpenDOS also come with a
CDS-loadhigh feature, and this is one of the reasons, why the pre-CDS
array is rearranged after CONFIG.SYS is finished. In this process,
some CDS values are changed and apparently some are just not copied
to the new target position. This is where we have to enhance OpenDOS
to allow fool-proof loading of NWCDEX etc. in CONFIG.SYS.
What's also interesting here, is the fact, that with it's
Win95 Microsoft copied most of Novell DOS' CDS-features, including
LASTDRIVE=1..32, the CDS-loadhigh feature, and by default 26 pre-
initialized CDS entries at startup, which will be changed to the
actual needed amount of slots before loading any programs by INSTALL=
etc. (this implies, that LASTDRIVE=/LASTDRIVEHIGH= now take effect
before this). And, it actually reports this lastdrive value in
SYSVARS during CONFIG.SYS.
So, I see three possible solutions for the problem:
- Adding a block device driver header to NWCDEX, which would fix
the problem for NWCDEX only. Since I've not seen it's source code,
I don't know how easy (- if -) this was.
- Adding my INSTCDEX utility's functionality to the kernel, though
this does not actually cure the problem, and is only a work around.
- Changing the kernel to do the same as Win95 does, which is already
quite similar to what our kernel actually does internally ;-)
. All these 26 slots should be reported in SYSVARS during CONFIG.SYS
(no problem at all)
. The CDS reassignment code at the end of CONFIG.SYS needs to be
changed somewhat, to copy all values as needed.
I'm sure, the developers already had this in mind, when they
implemented it this way in Novell DOS. However, the problem is,
that this opens a door for ill-behaving utilities like MSCDEX
now also being loaded in CONFIG.SYS, but using fixed pointers to
CDS entries in their code (Mind, CDS is moved after CONFIG.SYS).
At the times of Novell DOS, this would have been a compatibility
issue, and sure some people would have moaned, NWDOS wasn't
compatible... Nowadays, this might not be a problem any more, since
Windows95 does very similar. But because the CDS is already in it's
target position when MSCDEX is loaded, this is no problem in Win95.
For OpenDOS, this was still a problem and is *not* easy to fix,
because the CONFIG.SYS is interpreted, not compiled under this OS.
It was very difficult to change this and would require half of the
IBMBIO.COM code to be rewritten, also loosing some other DR DOS
CONFIG.SYS goodies...
Bye,
Matthias
PS: BTW, during the next weeks I will only partly participate
these lists due to my other work. Hope to 'see' you all
again, when I'm back and also hope, we can actually bring
OpenDOS some leap steps further than... ;-)
--------------------------------------------------------------------
Snail mail: Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany
New eMail : <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
Web : URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
--------------------------------------------------------------------
- Raw text -