JdBP>> I'm not convinced that it gains one anything, though. 
 JdBP>> It makes the situation a lot worse, in some respects.
 JdBP>>
 JdBP>> First of all, by introducing an extra layer of 
 JdBP>> indirection into the whole process, it doubles the 
 JdBP>> reconfiguration overhead.  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".
 JdBP>>
 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".

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

The flaw is that the scenario fails to take into account that the system API
is constructed around the paradigm of multiple drives with independent
directory hierarchies.  Not only would you have to rewrite the operating
system with a new API, you'd have to rewrite all of the applications programs
as well.  Try to find a non-trivial application that *doesn't* need to do such 
simple things as querying the current directory (a procedure that requires a
drive number).

So yes, one *does* have to have drive letters.  One *does* have to have two
separate tables that the user has to maintain and configure, doubling the
hassle of configuration.

This is, of course, unless you are classing the supporting of *all* currently
existing OS/2 applications, 16-bit and 32-bit, as mere "backwards
compatibility".  (-:

A far simpler scheme is to provide control over the assignment of drive
letters to volumes using some mechanism such as the DRIVELETTERS directive
that I described to Mike.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR
138/2
397/1