Ghost Kernel

Few days ago, a fellow programmer contacted me and revealed a project he has started:

MeetixOS - an operating system derived from the Ghost OS. It extends the kernel with some features and adds various applications.

https://github.com/MarcoCicognani/MeetiX-OS-Project

It is nice to see what's possible with the kernel already and what the Marco was able to build on top of it. Great work!

I'm very interested to see which way this project will go and how we can collaborate together.

Keep it up!

Sources version 0.5.6 are now in the GitHub repository! You can download the current demo file on the download page.

Made some improvements to the kernel and fixed a few minor issues in the libc and libapi. Improved how command line arguments are passed when loading binaries. Previously, the initialization routine running before the user's main function had to parse the arguments - now they are already parsed by gosh (the new Ghost shell) and provided bite-sized to the executable.

Most time was spent finishing the new terminal (that now responds well to escape sequences) and then starting a port of GNU bash. It depends on quite some POSIX/Unix functions that I had to implement/still have to implement to get it running. It compiles well now and tells me its version, but there is still some stuff to do.

Last but not least, I added a fancy boot screen to make it look a little nicer when starting up ;-)

Happy new year to all of you! :)

I rewrote the terminal driver so that it now uses VT100 for output. With this it is now possible that applications can control their terminal window by sending escaped commands.

This also allowed me to finally separate the shell implementation from the terminal itself (it was basically a "built-in shell" before). The shell is now found in gosh - the Ghost shell. This shell is still work-in-progress but will soon be enriched with various features.

What you see in the screenshot is a little demo - I ported the Duktape JavaScript interpreter and made it run a script. I'm thinking about using this as a replacement for what bash/sh usually do, but this is just an idea for now.

After debugging for many hours, I finally got the canvas implementation to work nicely. It is now possible to perform drawing on a free canvas from any application. This is implemented using shared memory between applications and the window server.

The new canvas implementation finally allowed me to add a GUI mode for the terminal!

Here's a little video of it in action. It's still a bit laggy though :o)

The latest commit includes a canvas implementation and the first steps for an actual desktop.

A canvas component is needed to allow applications to freely draw on a buffer in memory, which is usually only done by window server. The use case for this canvas is for example drawing a task-bar from within the desktop application or providing a space to draw images from client-side. It will also be the basis for other user-drawn components.

Unlike other UI components, the content of a canvas is entirely rendered by the component creator instead of the server. The implementation for this is done with a combination of shared memory and messaging. The client requests creation of a canvas component just as with any other component, and the window server notifies the client with events when the buffer has been allocated.

The most challenging issue with a shared memory buffer is avoiding the client application to cause faulty memory accesses when the buffer needs to be resized (i.e. after relayouting). This is now solved by simply retaining the previous buffer until the client application sends an acknowledge message to the window server. This consumes more memory until the buffer is acknowledged but improves stability. A nice little discussion on this topic was led in the OSDev forums.