Page 2 of 5
Re: A true webOS?
Posted: Sat Jul 21, 2012 9:51 am
by sandras
platform wrote:
GAT wrote:
I agree with piranha, partly.
It would be really be inefficient, but IMHO it would be fun to make!
And plus it could be really flexible if you built it right.
One issue I foresee is that you can't really do hardware stuff with scripting languages.
You could do like an exo kernel in native code that would interpret the javascript, and then have device drivers that the javascript or kernel could call to that were in native code.
Why not? "All device drivers are written in Java and executed by the virtual machine" (JavaOS, wikipedia).
Some devices will need things like "in" and "out" instructions which work with ports. Not even C, which is the most used language for kernel development because it's low-level enough, portable and efficient, can't do that. And it shouldn't. You WILL have to use some assembly.
Re: A true webOS?
Posted: Sat Jul 21, 2012 10:03 am
by GAT
Sandras wrote:platform wrote:
GAT wrote:
I agree with piranha, partly.
It would be really be inefficient, but IMHO it would be fun to make!
And plus it could be really flexible if you built it right.
One issue I foresee is that you can't really do hardware stuff with scripting languages.
You could do like an exo kernel in native code that would interpret the javascript, and then have device drivers that the javascript or kernel could call to that were in native code.
Why not? "All device drivers are written in Java and executed by the virtual machine" (JavaOS, wikipedia).
Some devices will need things like "in" and "out" instructions which work with ports. Not even C, which is the most used language for kernel development because it's low-level enough, portable and efficient, can't do that. And it shouldn't. You WILL have to use some assembly.
Precisely. Scripting languages just can't handle low level stuff like that. But you could call to some native code to deal with it.
Example: How do you read from a floppy disk in javascript?
You can't.
However you could have the javascript tell the kernel "Yo, get me some data on this sector from this drive" (Or better yet get me a file with this name and have the kernel figure out the drive and location!), then the kernel could call out to some daemon to grab the data and then send the data back to the javascript code.
Re: A true webOS?
Posted: Sun Jul 22, 2012 8:42 am
by Nable
Not even C, which is the most used language for kernel development because it's low-level enough, portable and efficient, can't do that.
> Not even C, [...] can't do that.
Looks like assidental double negation. And...
http://www.google.com/search?rls=en&q=i ... 8&oe=utf-8
Re: A true webOS?
Posted: Sun Jul 22, 2012 8:54 am
by platform
GAT wrote:
Precisely. Scripting languages just can't handle low level stuff like that. But you could call to some native code to deal with it.
Example: How do you read from a floppy disk in javascript?
You can't.
However you could have the javascript tell the kernel "Yo, get me some data on this sector from this drive" (Or better yet get me a file with this name and have the kernel figure out the drive and location!), then the kernel could call out to some daemon to grab the data and then send the data back to the javascript code.
Then... The kernel must be in C. Or... what about a microkernel in C which runs JSVM and then a kernel in JS?
Re: A true webOS?
Posted: Sun Jul 22, 2012 10:16 am
by GAT
Nable wrote:Then... The kernel must be in C. Or... what about a microkernel in C which runs JSVM and then a kernel in JS?
Kinda, technically the javascript interpreter would be the kernel, but that is the idea.
You could pria port an existing javascript interpreter to run on the bare metal and go from there.
Re: A true webOS?
Posted: Sun Jul 22, 2012 10:47 am
by platform
GAT wrote:Nable wrote:Then... The kernel must be in C. Or... what about a microkernel in C which runs JSVM and then a kernel in JS?
Kinda, technically the javascript interpreter would be the kernel, but that is the idea.
You could pria port an existing javascript interpreter to run on the bare metal and go from there.
Yes, I could port v8.
Bootloader => v8 and basic libs => kernel in JS
Something like that? If the answer is yes, I will start a project called "Boot 2 v8"
.
Re: A true webOS?
Posted: Sun Jul 22, 2012 12:12 pm
by GAT
Exactly! You will just have to replace all the system calls that v8 makes with actual code capable of running on the bare metal then you should be good to go.
Re: A true webOS?
Posted: Mon Jul 23, 2012 5:08 am
by platform
GAT wrote:Exactly! You will just have to replace all the system calls that v8 makes with actual code capable of running on the bare metal then you should be good to go.
Code in C++? Or code in JS? Sorry, I don't have understood this part.
I am going to start this project seriously. But I need to know in which web framework should I base the OS. For example, if I chose v8, I would have a problem: I should have to create a web render engine in... Javascript. So, then it would be better to boot Webkit or something like that, wouldn't it?
I have found an interesting project, called PhantomJS, which is a framework that runs Webkit in a "head-less" mode. But with that... Could I render a page (view a page)? Thanks.
Re: A true webOS?
Posted: Mon Jul 23, 2012 6:36 am
by platform
GAT wrote:Exactly! You will just have to replace all the system calls that v8 makes with actual code capable of running on the bare metal then you should be good to go.
Code in C++? Or code in JS? Sorry, I don't have understood this part.
I am going to start this project seriously. But I need to know in which web framework should I base the OS. For example, if I chose v8, I would have a problem: I should have to create a web render engine in... Javascript. So, then it would be better to boot Webkit or something like that, wouldn't it?
I have found an interesting project, called PhantomJS, which is a framework that runs Webkit in a "head-less" mode. But with that... Could I render a page (view a page)? Thanks.
Re: A true webOS?
Posted: Mon Jul 23, 2012 7:43 am
by platform
Re: A true webOS?
Posted: Mon Jul 23, 2012 8:44 am
by GAT
Cool. I knew this sounded familiar. Maybe use there interpreter.
But I don't think you need something as complex as v8.
http://code.google.com/p/tiny-js/
or
http://code.google.com/p/quad-wheel/
might be enough.
Re: A true webOS?
Posted: Mon Jul 23, 2012 8:47 am
by platform
OK, I gonna investigate this JSVMs.
But, a very important thing that I wanna ask: Imagine that one day I wanna have a graphical interface in my OS. Then, by design, I won't be able to render the HTML files without writting a render engine in JS.
What about booting Webkit?
Re: A true webOS?
Posted: Mon Jul 23, 2012 8:54 am
by GAT
Actually wouldn't it be better to write the html engine in javascript?
That would make the OS a lot closer to 100% javascript, and would be a lot cooler than using a pre-made engine
Plus Webkit is pria to complex and bulky, most likely it would be hard to supply it with everything it needs to run right.
Re: A true webOS?
Posted: Mon Jul 23, 2012 9:02 am
by platform
GAT wrote:Actually wouldn't it be better to write the html engine in javascript?
That would make the OS a lot closer to 100% javascript, and would be a lot cooler than using a pre-made engine
Plus Webkit is pria to complex and bulky, most likely it would be hard to supply it with everything it needs to run right.
OK, but the objective is not to have a Javascript OS, the objective is to have a web OS (what about booting PhantomJS, a head-less webkit framework?).
But, OK, you may have reason.
So, now I would have to boot TinyJS. It would be easier to base the project in JSOS but it cannot be compiled without Ruby, and I don't like that.
What do you think? Thanks.
PD: Wow! TinyJS is very, very simple! It's perfect for my project!
Re: A true webOS?
Posted: Mon Jul 23, 2012 10:16 am
by GAT
I guess you could render html using something in native code, I was just thinking that it would be best to use as little native code as possible.
As far as the JSVM I think it would be best to go with the one with the smallest possible footprint that still retains functionality. And plus the simpler it is the easier it will be to modify so it can run off the bare metal and provide basic kernel services.