OSDev.org

GAT wrote: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.

Yes, I am investigating TinyJS, because it's very simple.

By the way, could anybody give me the link of a C++ simple kernel? I wanna test something, and the wiki barebones are wrong.

platform wrote:the wiki barebones are wrong.

Proof wanted.

Combuster wrote:

platform wrote:the wiki barebones are wrong.

Proof wanted.

I think that the loader's code is wrong. It gives errors if you try yo assembly it. And I have searched it and there are other users with the same problem:

http://forum.osdev.org/viewtopic.php?f=1&t=21444

("the code in the wiki is so much wrong").

Please, could anybody gives me a very simple kernel in C++ (the source link)? Thanks.

That's both irrelevant to the C++ barebones for being FreeBasic code, and it's posted by someone who couldn't read instructions if his life depended on it and used the wrong assembler (notice that the thread is locked for breaking forum rules).

Combuster wrote:That's both irrelevant to the C++ barebones for being FreeBasic code, and it's posted by someone who couldn't read instructions if his life depended on it and used the wrong assembler (notice that the thread is locked for breaking forum rules).

Ok, then I apologize.

I have a kernel in C, and I am going to port it to C++.

I aim to have a C++ kernel that can input an output text,

Thanks.

There is a C++ bare-bones on the wiki. If you know how to input/output text in C, you can do it in C++ exactly the same way.

Tosi wrote:There is a C++ bare-bones on the wiki. If you know how to input/output text in C, you can do it in C++ exactly the same way.

Thanks. Now I am having problems to compile (the bootloader is for x86 architecture and I am on 64 bit system...).

Build a cross compiler and cross binutils to either target x86 or x86_64 depending on what you want.

platform wrote:

Tosi wrote:There is a C++ bare-bones on the wiki. If you know how to input/output text in C, you can do it in C++ exactly the same way.

Thanks. Now I am having problems to compile (the bootloader is for x86 architecture and I am on 64 bit system...).

Seriously? Whatcha even doing here?

MINIX + Custom server.
Have you heard of hv3. It uses this SEE ecmascript engine.

If you have a 64-Bits system, there are chances that it supports protected mode anyway. Else, you could use an emulator.
However, as you say you are new, I don't suggest you to get into the complexity of a 64-Bits architecture.

For your OS, is I understood everything clearly, you want it to have applications that use web languages and concepts.
You have to know that you can't do everything in JavaScript, as it does not support enough low-level things.

If your OS has to offer the user a webtech environment, you don't necessarily have to write it fully in web tech.
However, your kernel can be written partially in native languages.

I suggest you following these steps :
- In your bootloader, load the kernel binary and switch to protected mode (or whatever mode you like)
- At the loading of your kernel, some native code does setup the environment (enable paging, load GDT, setup ports...)
- Then, you had some basic functions to the kernel (written in native languages) to do everything that web tech can't do.
- Now, you implement your way to run Javascript
For this, know that you don't have to choose between compiled JS or interpreted JS. Just take both ! Have 2 types of executables: One containing Bitcode made by compiling JS, and the typical .JS interpreted files. Say .JSB and .JS for ex.
Note that this compiler must have built-in JS functions/objects that map to the native code functions that you wrote in the previous step.
- Once this works, you can program the remaining part of your kernel, but use the compiled JS engine for this, as it is much faster, and protects your code from virusses (modifying kernel.js) where Kernel.JSB, in compiled code, would always be locked (because it's being executed) and thus not changeable.
Your kernel MUST use the built-in functions mapping to the native code. However, don't make them available to user code.
- And then, write your native library. It could provide, for example, a function such as CreateFile, OpenFile, PlaySound... or be much more structured... Do as you like.
- Once you've got it, write what I call the "System Apps", that is, the applications that are part of the system. For example, the GUI and File Explorer.
- For your GUI, simply find inspiration in any popular Web Browser. Just create a window and render your web page inside.

Now, you have a basic system. What we've done is creating a layer encapsulating the low-level things that JS can't do.
If you want, for example, to implement OpenGL which you will probably need for better HTML rendering (and implementing WebGL), just implement your drivers in the Native Code part of Step 3, and interface them in JavaScript, so you can have all the OpenGL functions as JS functions. You could also go forward and implementing a full renderer interface such as Direct 3D's one.

Then, you can experiment and implement anything you like. I would just suggest you some possibilities :
- A Driver Model, to be implemented in the native code part. The native code should load the drivers which should be used to implement an abstraction library. For example, your Renderer Methods MUST use the graphics driver's methods.
- A Renderer for your web rendering engine, to provide a hardware-accelerated rendering. I suggest you to port OpenGL (which is FreeWare)
- A Graphical User Interface (GUI) with advanced possibilities. Don't try to copy the behavior of other systems, make your own one.

Finally, once you get a well-working system, you can think of implementing Network operations, to can load applications from the web (!)

Once you get into the shape of the native developper, you can implement many other things, such as a local server (based on Apache ?) which would allow applications to communicate as Web Apps do with the cloud.

However, keep in mind that a "Web OS" means much work. You will notive how often Web Browsers get updated, so you will need a strong updates system.

However, as you say you are new, I don't suggest you to get into the complexity of a 64-Bits architecture.

What kind of "complexity" are we talking about here? Other layout of paging structures? 64bit registers? Additional registers? Leaving segmentation behind? Much more space for different things in way bigger (well, ^2 bigger) address space? More standardized instructions to make a syscall?

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.

In JSOS I exposed a handful of I/O functions to kernel land: https://github.com/charliesome/jsos/blo ... l/src/io.c

While I don't have a floppy driver, I have an IDE driver written in JavaScript: https://github.com/charliesome/jsos/blo ... ers/ide.js and a read-only FAT16 driver: https://github.com/charliesome/jsos/blo ... s/fat16.js

The only Kernel primitives the IDE driver requires are four port I/O functions (Kernel.inb, Kernel.outb, Kernel.insw and Kernel.outsw). The FAT16 driver and the MBR driver (which sits in between the IDE driver and the FAT16 driver) do not make any calls to Kernel primitives.

So it is indeed possible to read from the hard drive with JavaScript given a small set of exposed 'primitives' written in C.

So, in general, you have very limited µkernel written in C, running VM running drivers written in JS. You can't hide the fact that it's not "JS OS", but rather a C OS with JS drivers ;D

Also, remember that `inX/outX` are obsolete and you will soon need to code some DMA routines in your C microkernel and export it to JS drivers.