Hi Jonathan,

 PK> [...]
 PK> While this is a MAJOR change in the concept of partitions and drive
 PK> letter assignment to DOS/OS2/Windows people, it 
 PK> is a change that may
 PK> not be that large or difficult to implement (he 
 PK> says innocently)........;-)

 JdBP> I'm not convinced that it gains one anything, though. 
 JdBP>  It makes the situation a lot worse, in some respects.

Here we strongly disagree. One gains the ability for the USER to control
things again, and not leave them up to the machine to arbitrarily define.

Note that I said "gains the ability". If the USER wants, he can do all this
manually. If he doesn't, then he can have the machine decide on these issues.
At least it puts the user back in control of things.

 JdBP> First of all, by introducing an extra layer of 
 JdBP> indirection into the whole process, it doubles the 
 JdBP> reconfiguration overhead.

Pardon? WHAT reconfiguration overhead are you talking about? And another layer 
of indirection is a non-issue, we ARE using computers that are suppposed to be 
good at carrying out the boring and mundain tasks that humans prefer to leave
alone. Besides, I can't see another layer of indirection at all, we already
have that with the "mapping" of physical volmes to logical drive letters! All
we are doing it mapping Physical drives to logical paths!

 JdBP> One has to have some 
 JdBP> naming scheme for the raw volumes and a table of 
 JdBP> mount directives, so that one can say "mount volume 
 JdBP> X,Y at this point in the directory tree".

Yes. A table that the USER builds, not the machine. 

 JdBP> One then has to have *another* table of drive letter 
 JdBP> assignments to say "drive letter Q: is this point in 
 JdBP> the directory tree".

ONLY if it is necessary to HAVE a drive letter there! Remember, in my scenario 
this is for backwards compatibilty only!


 JdBP> Second, whilst it may look superficially attractive one cannot in 
 JdBP> practice break the identity between a drive letter 
 JdBP> and a single physical volume without a major paradigm shift. This is 
 JdBP> because the operating system API itself is designed 
 JdBP> to allow (controlled) low-level access to raw volumes 
 JdBP> where necessary, and it uses drive letters to "name" 
 JdBP> those volumes.

I see 2 choices here -
  1. Map a drive letter to the physical object and all those OLD methods will
still work. The "low level" access really just becomes a high level one...
  2. Update the old S/W to change the object being addressed, from a drive
letter (Eg F:) to being a volume identifier (Eg: HD2:ACCOUNTS). Thats going
from 1 (or 2 if the colon is needed) bytes, to perhaps 20 bytes (I am being
generous). Note that SIMPLE in my terms means how SIMPLE it would be to
address te DEVICE, not how complex to implement.

Yes, MANY changes would need to be made and a lot of S/W would break in my
"native" scenario, UNLESS the USER (or system) "mapped" drive letters
appropriately. My preferred approach would see all these low level utilities
updated to use a much more useful approach to direct device access. 

 JdBP> Third, one has the problem that new volumes aren't 
 JdBP> automatically and immediately directly accessible.  

What problem? If the USER WANTS this to happen, then he sets the system up to
do it! At least he has the ability to control this process if he wants to.


 JdBP> With the proposed scheme one would have to manually add a new 
 JdBP> entry to the "mount" table before one could even access the volume.

For manual control yes, but this can also be done automatically.

What I would like out of all this is the ability to make these decisions
myself, rather than have the machine make them for me.

 JdBP> An alternative scheme, one that is similar but that doesn't have quite 
 JdBP> as many problems, would be to extend the Universal 
 JdBP> Naming Convention to include local volumes. 

Now you are really getting into it, and that would be how PHYSICAL devices are 
accessed, and how LOGICAL drive letters assigned! See, its not really that
hard.......;-)

The only catch here would be if the DRIVE ordering changed, but then the same
issue exists regardless of how one addresses physical devices.

 JdBP> So "C:\CONFIG.SYS" would expand, internally, to 
 JdBP> "\\.\HARDDISK0PARTITION2\CONFIG.SYS" .

Close, but too verbose and Windy like.....;_) Should be more like -
        \\.\HD0:WARP5\Config.Sys

One other annoyance is when the OS changes the NAME of a partition at install
time, now THAT could cause problems with multiple partitions set up with the
SAME OS.......;-)

 JdBP> I am told (not having ever seen or used it myself) that OS/2 
 JdBP> Warp Server version 4 assigns UNC names to local 
 JdBP> volumes in much this way, too.

Sounds like half the work is already done then.........;-)

Cheers..........pk.


--- Maximus/2 3.01