PLEASE HELP... I am newbie here with good c c++ coding skill
-
- Posts: 3
- Joined: Wed Sep 12, 2007 10:10 am
PLEASE HELP... I am newbie here with good c c++ coding skill
PLEASE HELP... I am newbie here with good c c++ coding skills.....
i want build a os in java.... for which i need kernel .......
how should i begin....? is it possible....?
please give suggestions.....
1000 thanks in advance
i want build a os in java.... for which i need kernel .......
how should i begin....? is it possible....?
please give suggestions.....
1000 thanks in advance
-
- Posts: 3
- Joined: Wed Sep 12, 2007 10:10 am
yes i agree
yes i agree to that i need a mechanism to support java vm ...
can it be done...? with kernel later it should support GUI also....
can it be done...? with kernel later it should support GUI also....
Java is not the language for an operating system to be written in. The bytecode makes heavy use of syscalls and is 'compiled' for a stack-based processor, not a register-based one like the x86.
Ain't going to happen, rethink your design goals.
And please stop using ellipses ("..."), they're really annoying when used all over the place.
Ain't going to happen, rethink your design goals.
And please stop using ellipses ("..."), they're really annoying when used all over the place.
-
- Posts: 3
- Joined: Wed Sep 12, 2007 10:10 am
NO NO my idea is different
i want to build mini OS in JAVA..... but the kernel must be in C/C++.....
will the kernel support JAVA VM....?
will the kernel support JAVA VM....?
- jerryleecooper
- Member
- Posts: 233
- Joined: Mon Aug 06, 2007 6:32 pm
- Location: Canada
I heard of some java microprocessor, based on forth processors. I don't know their value. http://en.wikipedia.org/wiki/Java_processor .
You would have to build a kernel in C/C++/assembler and then have functionality that translates java bytecode into x86 and runs it. And translates syscalls to your format.
Essentially what you have is a microkernel with java layered on top. So the operating system isn't written in java at all, it's written in C, with utilities written in java.
A kernel cannot be written in java, as it stands.
Use the correct tools to do the correct job. This is not a job for java.
Don't get me wrong, I'm not one of these people who naysay anything that isn't C - I think C# and singularity can go far. But you're really on to a loser if your language compiles to bytecode for another machine architecture. And yes I know C# compiles to MSIL, but the singularity project has tons of funding and tons of M$ engineers behind it.
[EDIT]My university supervisor is an integral part of that java processor project. It's not going to be active for a looooong while![/EDIT]
JamesM
Essentially what you have is a microkernel with java layered on top. So the operating system isn't written in java at all, it's written in C, with utilities written in java.
A kernel cannot be written in java, as it stands.
Use the correct tools to do the correct job. This is not a job for java.
Don't get me wrong, I'm not one of these people who naysay anything that isn't C - I think C# and singularity can go far. But you're really on to a loser if your language compiles to bytecode for another machine architecture. And yes I know C# compiles to MSIL, but the singularity project has tons of funding and tons of M$ engineers behind it.
[EDIT]My university supervisor is an integral part of that java processor project. It's not going to be active for a looooong while![/EDIT]
JamesM
javaOS
Now that Sun has opened sourced Java this project takes a huge step to being possible. Sun might not have the same dollar resources as MS, but the Java technology has been around a long time and written by some very smart guys & gals.
To do a JavaOS you will need some C, but I bet the Sun code doesn't use anything that isn't in a standard C library. So, if you have a stdlib you could be in business.
A nice thing you can do with Java & C# project is build an emulation layer in Java so to test and develop you wouldn't even need bochs etc and can use plain old java and tools.
Wish I had the time to do this
To do a JavaOS you will need some C, but I bet the Sun code doesn't use anything that isn't in a standard C library. So, if you have a stdlib you could be in business.
A nice thing you can do with Java & C# project is build an emulation layer in Java so to test and develop you wouldn't even need bochs etc and can use plain old java and tools.
Wish I had the time to do this
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Beware of the task ahead. It will not be easy.i want build a os in java.... for which i need kernel .......
Java is usually compiled to bytecode, but you can recompile that bytecode to x86. Wether you do that before you run the kernel or when the kernel is running is up to you. Since you'll probably have to build the recompiler anyway, its wise to consider its use as both JIT compiler and recompiler.
Java has several inherent problems you can't solve without resorting to other languages:
- It depends on a memory allocator
- It does not support port I/O
- It does not support processor-specific instructions.
- It does not natively support interrupts.
- It can not directly access certain pieces of memory.
The first one is probably the most interesting component - it has to provide memory management, and garbage collection for the kernel. Probably you want to have paging enabled as well and build a higherhalf kernel. Sources for that are available on the wiki. Next you need to build a physical memory manager system, which mainly include page_alloc and page_free. on top of that you need a malloc, and free, and on top of that you'll have to code the garbage collector.
After that, implementing the other points is pretty trivial.
Now you should write classes with native functions, after which you can link the precompiled java parts with the kernel and. Then after the memory allocators are initialized, you can jump to the java code and build the rest of the kernel in that.
Once you get there, you should be able to do the rest in just Java.
Now for the remarks of other people:
An OS is more than just the kernel. You can very well have a Java OS with a C kernel, you can even have a Java kernel even though it uses other bits and pieces (Compare: the linux kernel is written in C, even though it uses assembly)JamesM wrote:So the operating system isn't written in java at all, it's written in C
You remind me of the lot that refused to believe that you could code an OS in Basic, why not Java?Ain't going to happen, rethink your design goals.
compiled byte code & jit
No need to worry about that. The Sun Hotspot vm takes care of that for you.
In a way JIT compiled code is better than regular compiled code because when you compile you have to target the least common denominator target CPU (or provides lots of libraries). JIT compiling knows what michine it's running and can optimize as it goes. So on a super whizzy CPU you get super whizzy code.
In a way JIT compiled code is better than regular compiled code because when you compile you have to target the least common denominator target CPU (or provides lots of libraries). JIT compiling knows what michine it's running and can optimize as it goes. So on a super whizzy CPU you get super whizzy code.
Hmm, I really should reread my posts when posting after a long day at work. It kind of shows! Was a leeeeetle bit ranty there wasn't I?JamesM wrote:You would have to build a kernel in C/C++/assembler and then have functionality that translates java bytecode into x86 and runs it. And translates syscalls to your format.
Essentially what you have is a microkernel with java layered on top. So the operating system isn't written in java at all, it's written in C, with utilities written in java.
A kernel cannot be written in java, as it stands.
Use the correct tools to do the correct job. This is not a job for java.
Don't get me wrong, I'm not one of these people who naysay anything that isn't C - I think C# and singularity can go far. But you're really on to a loser if your language compiles to bytecode for another machine architecture. And yes I know C# compiles to MSIL, but the singularity project has tons of funding and tons of M$ engineers behind it.
[EDIT]My university supervisor is an integral part of that java processor project. It's not going to be active for a looooong while![/EDIT]
JamesM
Apologies.
basicly to run java you need to have a platform that the vm can run on
Howether u also need native code for other higher level functions
eg at lest part of your GUI has to be in non java code then linked by JNI or something simlar
the same aplise to drivers if whant to write even a small amount of your os in java you have to dump most of the standered libarys includeing part of java.lang ak Threads , Runables and all things asosiated whith them
Howether u also need native code for other higher level functions
eg at lest part of your GUI has to be in non java code then linked by JNI or something simlar
the same aplise to drivers if whant to write even a small amount of your os in java you have to dump most of the standered libarys includeing part of java.lang ak Threads , Runables and all things asosiated whith them
.................................. um what should i put here .............................?..........................................
..... ................
..... ................
Java libs
The UI is an interesting thing. I think it's possible to do this (I've seen it done in the mobile world) in 100% Java. At some point some Java code needs access to memory buffers though.
As for standard libs, in the mobile world they are nearly all written in Java so no need to drop. Also VM can implement threads in at least 2 ways. The first is to use the underlying platform threads (win32, posix etc) or more interstingly the vm does all the threading itself. That is the vm runs in one thread and any java threads are handled in that single thread.
Drivers would pose some interesting problems as you'd have to come up with some kind of interrupt mechanism, memory & device access etc.
As a hobby project it maybe too much to do, though if you have plenty of time it will certainly keep you occupied for a while
As for standard libs, in the mobile world they are nearly all written in Java so no need to drop. Also VM can implement threads in at least 2 ways. The first is to use the underlying platform threads (win32, posix etc) or more interstingly the vm does all the threading itself. That is the vm runs in one thread and any java threads are handled in that single thread.
Drivers would pose some interesting problems as you'd have to come up with some kind of interrupt mechanism, memory & device access etc.
As a hobby project it maybe too much to do, though if you have plenty of time it will certainly keep you occupied for a while
mobile java libs are different also most of the java.?.? and javax.?.? use JNI (which requires standard c libareys) to access c files also java.awt and java.swing use the underlying oses windowing toolkit. thought it is easy not to notice this it is most likely to work if you don`t use any of the standard libraries thought this is very hard
.................................. um what should i put here .............................?..........................................
..... ................
..... ................
As for standard libs, in the mobile world they are nearly all written in Java so no need to drop. Also VM can implement threads in at least 2 ways. The first is to use the underlying platform threads (win32, posix etc) or more interstingly the vm does all the threading itself. That is the vm runs in one thread and any java threads are handled in that single thread.
the java.lang.thread class or a class it requires i can`t rember which makes a call to native code outside the vm so this is likely to be incorrect unless its for mobile vm which is different and has different thread class
.................................. um what should i put here .............................?..........................................
..... ................
..... ................