Ghost Kernel

Terminal VT100 support, separate shell implementation 2017/01/14, 16:30:08

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.


Terminal upgraded for GUI mode (Canvas fixed) 2016/08/19, 18:27:34

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)


Canvas implementation, desktop application 2016/07/11, 21:08:20

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.


Version 0.5.3 - Demo image, Cairo rendering, new tools, documentation 2016/05/13, 19:05:32

This release contains a whole bunch of new features and improvements. The window server rendering backend has been completely rewritten and now uses the cairo graphics library. Overall stability has been improved with various changes to the kernel.

Try it out yourself! Get the demo image.

The new sources are available on GitHub. I started writing a documentation that is in the repository too and be compiled using ASCIIDoc, for those who are interested in technical details of the kernel.


Cairo / Removed old messaging interface / Documentation 2016/04/09, 21:06:41

In an effort to get some proper painting I decided to port the cairo graphics library, which has advanced painting and nice performance. This made the UI a little bit faster in general. There are still some things to do (text fields must be fixed to work for cairo), but the overall experience with the library is great so far.

The obsolete messaging interface (g___send___msg, g___recv___msg, g___recv___topic___msg) was removed from the kernel. All applications that previously used it are now using the new interface that supports arbitrarily sized messages (g___send___message, g___receive__message).

Last but not least: I've been working a lot on a nice documentation using asciidoc, which will go online soon and be continuously updated and complemented.