I like your ideas, and I look forward to seeing them implemented
.
I think that there is a place for the command-line shell in a desktop OS. I think a graphical file manager and a command-line shell fulfil two different roles. A GUI file manager is like getting your hands dirty and doing it yourself (opening folders, dragging and dropping files, etc.). A command-line shell is like ordering someone else to do what you want: you tell it what you want doing and it goes off and does it. For example, Windows Explorer and CMD.EXE fit these two roles nicely, and I use both regularly.
I think that giving names to devices is more-or-less the same as giving them DOS-style drive letters. It's somewhere in between drive letters and subdirectories under /mnt. I don't particularly like either of these, but there's a thread in alt.os.development at the moment (called "a: vs /root") which discusses various alternatives.
On the subject of loadable modules: I'm thinking about a scheme for object naming and method dispatching. In a mainstream OS you have various objects (files, processes, users, etc.) each with their own naming conventions/namespaces (file names, process IDs, user names) and sets of functions. What I'd like to do is to unify the namespace: not to turn everything into a file (as Plan 9 does) but to turn everything into an object, with a file (and a process, and a user, etc.) being a special kind of object. I'm impressed by technologies such as COM and CORBA, so what I'd end up with is kernel syscalls like:
Code:
status_t ObOpenObject(const wchar_t *path, const IID& interface_id, void **object_pointer);
status_t ObCreateObject(const CLSID& class_id, const IID& interface_id, void **object_pointer);
Here ObOpenObject gives you access to the master kernel namespace of objects, which might look like:
/Processes
0
1
2
/FileSystem
FloppyDrive0
Storage
OperatingSystem
MyFiles
CdRomDrive0
/Users
Tim
Admin
Guest
Each 'file' in the namespace is actually an object, which supports several interfaces. When you call ObOpenObject you request one specific interface (such as IID_IProcess). An interface is effectively a C++ class without any member variables. Each interface supports, at a minimum, the IUnknown interface, which provides reference counting (AddRef and Release) and a method for obtaining pointers to the object's other interfaces (QueryInterface). When you call a method, you'd always be calling some code inside the current process; however, that code could either carry out the method to completion (like thisProcess->GetStandardOutput()) or invoke a syscall which would cause the method to run inside another process and return the results to you. In effect, the kernel becomes a namespace manager and inter-process communication system.
Of course, none of this is particularly new, it's just my take on things.
Login
Register
FAQ
Search
