Date: Fri, 27 Jun 1997 16:55:07 +0100
From: Matthias Paul <PAUL-MA AT reze-1 DOT rz DOT rwth-aachen DOT de>
Subject: Re: nwcdex
To: opendos AT delorie DOT com
Reply-to: Matthias DOT Paul AT post DOT rwth-aachen DOT de
Message-id: <108787C2DD8@reze-1.rz.rwth-aachen.de>
Organization: Rechenzentrum RWTH Aachen
Content-transfer-encoding: 7BIT
Precedence: bulk

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 
--------------------------------------------------------------------