On Wed, 28 Jan 2004, [ISO-8859-1] Björn Fischer wrote:
In fact I'm someone who dislikes driveletters
(please don't beat me ;-).
I like the Unix-style filesystem. I also like the Unix paradigma that
everything is treated like a file. By this you have a unique way to
access files, devices and everything else.
Actually, NT sort of has this. The executive treats everything as an
object which is some structure that is of a certain class (again, an
object) and has a set of methods. The objects are arranged in a tree and
the tree is "owned" by the object manager.
Win32 drive letters are simply mounted objects in the tree under the
branch of DosDevices that have their own parse methods.
So lets say you have X: as your drive letter, thats \DosDevices\X:\foo\bar
to the object manager. The "\foo\bar" part is passed to X:'s parse method
where it handles filename lookup and then returns a file object (from the
I/O manager).
Removing drive letters all together would cause some serious problems for
existing Win32 apps but I wonder how much trouble it would cause to create
a symlink under \DosDevices to \DosDevices so you get a single "super
drive" letter.
If you want to be really daring you could create a symlink under
\DosDevices to the object tree root and then get access to everything via
one interface. In fact, named Win32 objects like semaphores and mutexes
are also there under \BaseNamedObjects, IIRC.
The same is with mounting drives somewhere in the
file-tree. I think
this way of drive access is much more elegant than assigning a letter to
each drive. Has anybody ever tried what happens whe trying to use 27
devices under Windows? Will it use two letters then? Or numbers?
Actually, NTFS supports reparse points that do this. But its up to the
filesystem since the parse method for X: ends up in the IFS code.
I think drive letters are a relict from old DOS times.
And now that
anybody is used to it there's no need to replace it by a better solution
(because people don't like to throw away what they understood once and
what they got used to).
Right, but changing the Win32 API is bound to break compatability; and
thats an important goal of ReactOS. But thats okay, the architecture of NT
allows for more than one subsystem. You could write a Native API program
if you really wanted to (most of the Win32 facilities are there for you in
"raw" form) or you could write your own OS API via a subsystem.
I guess it wouldn't be too hard for somebody to code up an alternative
protected subssytem to give a much more object-oriented API than Win32.
Programs that are not concerned with backwards compatability could use the
new runtime environment.
I totally agree about things being more uniform. When they designed the
Win32 API backwards compatability was an important goal -- I personally
think the Presentation Manager API is much better than the windows one (it
makes more sense rather than all the "non-client" special casing). But
they chose that for backwards compatability.
Hell, there is still the Global and Local memory API's.
Personally I think we should leave the Win32 API in ReactOS as is for
backwards compatability but we should encourage (eventually) the writing
of another subsystem for a nice, object-oriented API. The two can co-exist
quite easily.
In fact, a lean-and-mean subsystem would be just the thing for embedded
applications that have no need for backwards compatability. And that could
be a decent application of ReactOS on its own -- there is money to be made
in the embedded world with GPL code. ;-) Well, I used to believe that
anyhow.
L8r,
Mark G.