iProgramInCpp wrote:
Something similar is already being done by Windows NT.
There is an internal "object namespace" whose structure is very unix-ish, for example, "\Device\HarddiskVolume1" is a valid path within the NT object namespace. This is, however, only exposed as say, C:, in the Win32 APIs.
There is no c:\device path in my Windows 10 at least, but I suppose they want to hide this from end users.
OTOH, devices were already added to the FS in MSDOS, so I don't see the news value in it. And things like comports are opened using special pathnames.
However, it doesn't surprise me that they "steal" bad ideas from Unix. I've completely removed the DOS device file support, and I'm not adding any new support for devices in file systems. Bad ideas should rest in peace.
BTW, I'm not going "everything is a file" either. That would be contrary to my "handles refers to objects" idea, unless I imply that all objects needs to have read/write methods, which certainly is not the case.
I even "ditch" the read method in my new filesystem as it would be a slow version of doing syscalls when they are not necessary. The new way to handle files is to issue map requests, not to issue read requests.