OSDev.org

This is an idea i have been having.
Since people do have difficulties to unify their designs i had this idea. An os whose "kernel" as i call it will be a Java Virtual Machine (written maybe in c or c++).
The virtual machine will provide full support for all types of abstractions at the hardware and software level.
A "shell" will sit on top of the whole kernel and provide application programs with interface with the kernel.
All application programms could then be written in Java and run.
The problem of program portability will be resolved in no time.
Is this an utopia or can it be feasible.

There are a number of operating systems going (and many more trying to go) along this route. One of the most famous is Singularity, a research OS from Microsoft that aims to implement most of the operating system in .NET bytecode (whatever that's called, I can never remember). There are of course many others, including a few on this board. Perhaps most interesting is Singularity's white papers, which are free to download and have much good information.

I think this sort of thing is a great idea, and should be encouraged. Needless to say, it's sort of what I want my OS to be like in the future (whenever I find time to sit down and code it)...

Actually, singularity runs everything in native code. It just uses the bytecode to establish proof that a program is safe before compiling it. Interesting nevertheless.

There are also processors that run java bytecode natively. The main problem with this kind of things is that by restricting programs to java, you deny programs access to features which are not provided through the language. Think of vector math and specialized synchronization instructions.

Interesting: yes
Utopia: no

Thanks for the replies,
The whole system could be made more flexible since our virtual machine is an OS itself,not to bother about vector types and others.....some liberty can be given at that level to the application programmer.

Notable systems that use(d) high-level languages in userland are Smalltalk systems (not an OS, but see Squeak), Lisp machines, and Forth systems (Forth is still pretty low-level). I agree that this is a fantastic idea, and this is the goal of my project as well (surprise! though it's going to be an application first, not worrying about low-level kernelness at this point). As long as the system provides a way to access the underlying architecture, the language can still be extended from within (eg. adding vector types depending on CPU capabilities).

The lower the levels of your OS are that use the high-level language, the more the performance of the VM becomes critical. Sun was able to get Self's compiler to produce code up to half as fast as optimized C, for a very dynamic language, so it is definitely feasible.

I'd like to see how efficient drivers written in a high-level language can be.

An idea of mine

very not true.
this is not an idea of yours.

i'm pretty sure everyone who try to develop an OS want to make a direct jmv just because it is the tendance.

i have a friend of mine who told me that if i make it, he will use my OS.
he told me that 2 years ago.


utopia: not at all
feasable: yes, very yes.
hard to do: very very hard to do.
java have more than... 1000 classes. and need more than... 1000 systems api to work.

this cannot be done by a single programmer in one life time (~60 years)

I don't care about what the others think since at the moment the idea came,i did not copy the idea from someone.If someone has the same idea as me then fine(in any case,its hard to have an idea alone in this world).
Secondly,its only an idea.Not though yet of an implementation and when it will need to be implemented,i will not do that alone.

edfed wrote: java have more than... 1000 classes. and need more than... 1000 systems api to work.

this cannot be done by a single programmer in one life time (~60 years)

Who says you have to write all those classes? you only need to, for example, re-use existing .net classes (java should be the same i think), write the hooks from those classes to the underlying OS and presto! (that's what we're doing with sharpOS)

By adding .net into the equation you're multiplying the complexity factor... Think 1000 x 1000 API.

Who says you have to write all those classes?

me.

because the reason to use existing **** in new os will produce a very bad program.

rewrite all classes by reading existing ones, and avoid many layered errors by implementing compact source.

it is the theory of evolution. exactlly as DNA will evolve, code shall evolve too. and using middle age code for future os is a pure misconception.
making this would be avoided and then, you may prefer to use an existing os too.

and generally, using an existing HLL in a new concept is another misconception. code for linux if you are interrested in HLL.

edfed wrote:because the reason to use existing **** in new os will produce a very bad program.

rewrite all classes by reading existing ones, and avoid many layered errors by implementing compact source.

**** or not, there is a ton of software written in Java. The only reason I can see to rewrite the existing classes would be for efficiency; if one of the goals of the project is portability, you couldn't change the interfaces of any of the core libraries, and Sun isn't stupid about implementing them.

edfed wrote:using middle age code for future os is a pure misconception [...] you may prefer to use an existing os too.

and generally, using an existing HLL in a new concept is another misconception. code for linux if you are interrested in HLL.

One problem with writing your own kernel for a HLL OS is the need to reimplement lots of drivers, so agreed, trying to strip down another OS (ie. Linux) and build your own from it might be easier, even if it's just to start with. You're starting with drivers and software you know work, and you can gradually build your own in the HLL.

As well, it's much much easier to debug the HLL when you know the OS is stable and have wonderful tools like gdb . If your language isn't going to use the GNU environment though, might as well strip it out, and then you're getting into kernel work to get Linux to load and talk to your OS.

I'd recommend starting writing as an app for the OS you're running, and keep the external dependencies low but use wrappers around libraries that are already available, so when you decide to become fully self-supporting it's an easier transition, while you still have functionality in the mean-time.

Khumba wrote:Notable systems that use(d) high-level languages in userland are Smalltalk systems (not an OS, but see Squeak), Lisp machines, and Forth systems (Forth is still pretty low-level).

I've heard about the LispM... does anyone know where I can find a setup-disk/image? (I'll put t right on my VirtualPC...)

Khumba wrote: I'd like to see how efficient drivers written in a high-level language can be.

THAT is a very good question. I'm quite interested in that as well. I was wondering about the possibility of a device/driver system where the devices were visible to the system as objects... like Delphi's VCL tree is to the Windows API. (If that makes sense.)

I was also kicking around the idea of integrated, intrpreted code... so you could, in effect have your MP3 files as objects that know how to play themselves, or instantly debuggable device drivers. I'm not sure how feasible that would be, but it's a thought, eh?

IIRC, Lisp Machines were built on top of non-standard hardware. So the "Lisp machine" is actually a physical box. Think of it like a Mac: Hardware and software together.

Khumba wrote:

edfed wrote:because the reason to use existing **** in new os will produce a very bad program.

rewrite all classes by reading existing ones, and avoid many layered errors by implementing compact source.

**** or not, there is a ton of software written in Java. The only reason I can see to rewrite the existing classes would be for efficiency; if one of the goals of the project is portability, you couldn't change the interfaces of any of the core libraries, and Sun isn't stupid about implementing them.

edfed wrote:using middle age code for future os is a pure misconception [...] you may prefer to use an existing os too.

and generally, using an existing HLL in a new concept is another misconception. code for linux if you are interrested in HLL.

One problem with writing your own kernel for a HLL OS is the need to reimplement lots of drivers, so agreed, trying to strip down another OS (ie. Linux) and build your own from it might be easier, even if it's just to start with. You're starting with drivers and software you know work, and you can gradually build your own in the HLL.

As well, it's much much easier to debug the HLL when you know the OS is stable and have wonderful tools like gdb . If your language isn't going to use the GNU environment though, might as well strip it out, and then you're getting into kernel work to get Linux to load and talk to your OS.

I'd recommend starting writing as an app for the OS you're running, and keep the external dependencies low but use wrappers around libraries that are already available, so when you decide to become fully self-supporting it's an easier transition, while you still have functionality in the mean-time.

Actually I was using DOS and TP7 (with the Runtime Error 200 bug patched) to program my OS. I found a bootloader that would load any EXE or COM file on the internet and, as long as you don't use the DOS functions your program/OS works just fine. (I know some people might cringe knowing I'm {currently} using BIOS functions to grab the keyboard input... *shrug* let `em.)

You get some interesting side-effects of doing it this way, like no memory management or IPC to get in your way and the use of the TP7 environment for developing. (As well as the debugger.)

Actually, it seems to me like DOS would be much more of a OS-dev platform than Linux/Unix because, to quote one prof I had, "DOS isn't a real operating system, it has no memory management or IPC!" (Yeah, it's the same point as above, but I just find it rather amusing that the qualities that prof critisized for lacking are precisly the ones which obstruct OS-devers on Linux.)

Yayyak wrote:IIRC, Lisp Machines were built on top of non-standard hardware. So the "Lisp machine" is actually a physical box. Think of it like a Mac: Hardware and software together.

Ah, I see. I had suspected that might be the case from what vague refrences I've seen. It's good to have it confirmed. (Though I would still like to be able to play with it, you know?)