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.