
Every hard-core OS aficionado has done it: Laid out a grand scheme for creating the perfect OS. Taking all the best features and attributes from the OSes we love, and making sure to assiduously avoid the pitfalls of the OSes we don't. Maybe our goals were modest, and we just wanted a slightly tweaked version of an existing OS. But sometimes we're feeling ambitious, and we have large, creative ideas for revolutionizing computing. Long-time OSNews reader and contributor J. Scott Edwards just couldn't help himself, and he has set about to not only plan, but to try to build his dream OS.
However, the problem with the approach is that though it adds convenience for programming, (no file IO data required etc), each object oriented language has its own semantics and quirks. The biggest challenge will be to converge upon a set of OO semantics which all languages running on the system conform to. Also, it might be risky to stick to the OO paradigm for an OS is the OS is supposed to be used for other progamming models to. Eg. the functional programming models or the newer distributed communications programming model. All of this goes pretty messy. However, if you want to look more into data persistence and other cool stuff that could go into an OS take a look at tunes.org. I am sure you won't be dissapointed.
A good way to approach this problem will be not to start making an OS from scratch but use an existing OS like Linux and make a new "userspace" in it. Currently the userspace in linux is predominately 'C'. All binaries finally depend on libc and you know how the whole thing works. Any thing else (python, perl, Ocaml, Lisp etc) require a 'C' layer beneath to function. You could remove this dependency completely by making a compiler and linker toolchain. Consider Java as an example (though not a very good example as it does have C dependencies). Java has its own language, compiler, and linker. Hence it is possible to think of a userspace implementation of Java which loads and runs its own programs natively (using syscalls only) and not depend on the 'C' userspace. Now you might have the freedom of doing cool API and language tricks.
I previously had thought lot about these issues. I am personally in favour of "automated" data storing and retreival rather than pushing the abstraction right till the language runtime level. Data import and export libraries. Usage of RAM as a cache for the disk will be a cool idea but this also means strictly using the memory images for usage on disks which might not be a good idea for a number of reasons. However, one might still think of using a data exporter flush the moment some RAM needs to be reaquired (instead of pushing all the raw memory data onto the swap.)
Before I conclude, let me just warn you that it is very easy to fall into the trap of "object orientation is convenience" myth. However, a deeper understanding of typing theory and how OO fits into it will tell you just how incomplete the current OO paradigms are.
Anyways, this post is not a means to discourage you. Hope that your ideas turn into something concrete and well thought out.
Ritesh