JdBP>> What mechanism *would* you have to assign drive letters, then ?

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

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

First of all, by introducing an extra layer of indirection into the whole
process, it doubles the reconfiguration overhead.  One has to have some naming 
scheme for the raw volumes and a table of mount directives, so that one can
say "mount volume X,Y at this point in the directory tree".  One then has to
have *another* table of drive letter assignments to say "drive letter Q: is
this point in the directory tree".

Second, whilst it may look superficially attractive one cannot in practice
break the identity between a drive letter and a single physical volume without 
a major paradigm shift.  This is because the operating system API itself is
designed to allow (controlled) low-level access to raw volumes where
necessary, and it uses drive letters to "name" those volumes.  One would not
only have to redesign the FORMAT program so that it takes a raw volume name
("X,Y") instead of a drive letter, one would *also* have to redesign the
underlying operating system API so that access to raw volumes wasn't done in
terms of drive letters.  And this would break *all* existing disk utility
programs, such as the Graham Utilities for OS/2.

Third, one has the problem that new volumes aren't automatically and
immediately directly accessible.  Whatever one may dislike about the current
scheme, at least it is "plug in and go" in as much as if one adds a new volume 
it gains a drive letter automatically without any further effort.  With the
proposed scheme one would have to manually add a new entry to the "mount"
table before one could even access the volume.

An alternative scheme, one that is similar but that doesn't have quite as many 
problems, would be to extend the Universal Naming Convention to include local
volumes.  Volumes would automatically be assigned names such as
\\.\HARDDISK0PARTITION2 , which one could use directly as UNC path prefixes if 
one liked.  This avoids the third problem above, since it means that all
volumes are automatically recognised and immediately accessible, and
eliminates the first problem since by assigning UNC names automatically one
doesn't have to have a manually created configuration table of "mount points". 
 The second problem is resolved by having drive letters mapped onto these UNC
prefixes.  (Indeed, one might be able to extend those parts of the 32-bit OS/2 
system API that currently only deal with drive letter assignments to remote
filesystems to include local filesystems as well.)  So "C:\CONFIG.SYS" would
expand, internally, to "\\.\HARDDISK0PARTITION2\CONFIG.SYS" .

This is, of course, very close to the way that Windows NT actually operates
internally.  I am told (not having ever seen or used it myself) that OS/2 Warp 
Server version 4 assigns UNC names to local volumes in much this way, too.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR
114/477
143/1