Usually every time there is some article about operating systems implemented
in GC enabled system programming languages, those systems get dismissed as toy
operating systems by the community at large.
There are many reasons why that is the case. A big one is that the majority of
operating systems developed in such a way never go beyond simple command line
support. As they tend not to be much more than proof of concept.
Some examples of such operating systems are:
Another one is that no major commercial OS vendor is interested in investing into
bringing such concepts into the mainstream, as their current offerings are already
good enough for keeping their profits high, and they rather push incremental improvements.
As a consequence of such issues, a typical assertion by developers unware of what
has been achieved in the academia, is that using a GC enabled systems language is
only possible thanks to the simplicity of the designed system.
This is actually not true, as there have been a few research OS targeted for single
user graphical workstations, that were far more advanced that the listed operating
At the Swiss Federal Institute of Technology in Zurich, known as ETHZ, the following ones were developed:
All of them used even by researchers as their work system.
Oberon is the operating system, implemented in the Oberon programming language for the
Ceres Workstation. Both devised by the professors Niklaus Wirth and Juerg Gutknecht at ETHZ.
Oberon was influenced by the Mesa/Cedar environment that Niklaus Wirth got to use when he visited Xerox PARC
during his sabbatical time spent there, around 1976.
The Oberon operating system was developed around 1985, with Assembly use being reduced to the bare essential parts, like boot loader,
low level APIs for device drivers, graphics blitter and the initial GC implementation. With everything else being coded in the Oberon programming language.
The image below shows how the operating system looked like:
As it can be seen from the screenshot above, the operating offered already offered a minimalist graphical user interface.
The Oberon operating sytem deployed on bare hardware tends to be known as Native Oberon, to differentiate from the versions that were later developed to run on top of mainstream operating systems. It also helps to distinguish the operating system from the systems programming language used on its development.
The Oberon language supports the concept of modules and they are dynamically loadable in Native Oberon. This
feature, coupled with its OO model of single inheritance subclassing, offered an extensible system similar
to the Cedar environment already mentioned.
Any Oberon procedure can be made available to the user as system command, provided certain conventions are followed. They are known as Tools in Oberon literature.
In a similar way to Cedar environments, using such a system, it is possible to allow such Tools to act on user
interface elements selected by the user.
The complete system offered tooling for text editing, compiling, printing and so on. Several ETHZ
professors and studends, used in the system in their teachings, oder even as their main operating system.
The implementation of the operating system is described in the book called Project Oberon: the design of an operating system and compiler.
A PDF version is available from Professor Wirth's website, as listed on this article references.
A video posted by an Oberon user to YouTube, gives a glimpse how the system worked. Well worth watching, even without accompaning descriptions.
There is also another video from the original Ceres system being shown.
The last known version was Oberon v4.
Eventually a more modern user interface framework was introduced around 1998, named Gadgets, which gave Native Oberon a more modern look and feel.
As can be seen from the screenshot below, taken from Niklaus Wirth's Project Oberon book, the user interface was already more in line with what systems like Amiga and RISCOS used to offer. The copyright belongs to him and I took the liberty to copy it here, as there are very few screenshots that show a good overview of the operating system in use.
More screenshots can be seen at an older version of ETH Oberon Home Page.
The EthOS, also known as Extensible OS, was an attempt to move beyond the ideas of the original Native Oberon in terms
of system extensibility.
The systems programming language used for designing the system was Oberon-2, an evolution of Oberon with support for ...
The key points achieved by EthOS were:
A research paper about the implementation is available at ETHZ.
The main goal of the system, was to make some of the original closed modules from Native Oberon into extensible ones. As well as, improve some of the weak points of the original operating system, like GC features, mainly weak pointers and finalization.
The Active Oberon System was the result of the increased interest of the ETHZ researchers in the field of parallel computing, nowadays known as Blue Bottle or AOS.
It was originally known by A2 or BlueBottle, using an evolution of Oberon known as Active Oberon.
The main features of Active Oberon with regard to Oberon-2 are:
From all described systems, it is still possible in 2014 to get hold of some versions of AOS, as such what follows is an introduction to AOS.
There are some ISO image available at Oberon Community Platform, which gets some occasional updates.
The ISO images can be downloaded from http://sourceforge.net/projects/a2oberon/files/.
You can either install it into a real system, or into a VM environment like VMWare.
Due to the limited set of supported hardware, I advise to install it into a VM environment as it is easier to configure.
When the operating system sucessfuly boots, you will be greated with the following screen:
The AOS system is actually a live version, so like many mainstream operating systems offer nowadays.
For installing it into the hard disk, the installation program needs to be started by selecting the option Installer under the System menu.
As in any modern operating system installtion, there is a set of packages to choose during the installtion process:
Before the installation can proceed, the set of desired selections needs to be confirmed:
Afterwards a progress dialog gets displayed:
Until the finish installation message is finally displayed:
After a reboot, it is then possible to start using the AOS operating system.
Being used mainly for research activities, there are not much applications available out of the box.
There are however quite a few, which enable to show the desktop focus of the operating system.
This section will show an overview of the installed applications.
The usuall text editor to change the contents of any text file.
How to navigate the set of existing files and directories.
The original filesystem has a flat structure, however additonal filesystems can be pluggable via modules.
Although the need for optical media is deminishing, the occasional need to write CDs can be fulfilled via the CDRecorder application.
Creating a data project with CDRecorder:
Available disk operations:
The Slideshow application allows the users to browse their picture's archive.
For watching those nice videos during leisure times, a video player is also available.
A basic raytracer that takes advantage of the multitasking capabilities of AOS.
In the time and age of HTML5, AOS's browser is not going to earn any brownie points, but it is still
capable of rendering the original and actual AOS web sites.
In a operating system designed to share the hardware with other systems, a way to partition the
hard disk is always handy.
Information about how the operating system is behaving is also available.
The overall CPU/Memory usage:
Network usage by the overall system:
Overall system information:
Plugins used extending the system:
Module object usage by application process:
For those moments when an application misbehaves by doing some kind of ilegal operation or breaking expectactions,
a TRAP report is presented in the familiar stack trace form.
Like many desktop environments, AOS also supports themes in the form from skins. Here the Christmas skin in action:
The AOS system provides a version of Native Oberon System 3, with the system modules built on top of
AOS kernel. As such it allows for AOS users to experiment the Oberon operating system as if it was an AOS application.
The screen shows a typical Oberon System 3 session, with a text editor open, log pane and several tool panes.
In such environments, users tend to be developers as well, so there are a few tools for developing applications also available.
A code editor is available for developing new applications, with syntax highlighting, automatic capatelization of keywords and module browser.
The GUI Editor eases the work of creating graphical interfaces for applications, similar to RAD tooling available in other languages.
The Inpector is a form of UI debugger for applications, by instropecting into the component tree used by applications.
A simple tool to see differences between text files.
Currently AOS still receives some new code occasionally, althought very slowly, as those features tend to be the focus of some research topic.
There has been an attempt to port it to the Raspeberry Pi, but it appears to be stale now.
Sadly the current state of affairs means that the industry is still not fully receptive to the
ideas presented by these systems.
OS/400 with the kernel JIT, Android with the Java based userland and Windows Phone 7/8.x with their .NET/WinRT runtimes are the best approaches to these ideas, but they are still done at the userland level.
None of the major OS vendors has shown any desire to use safe languages in kernel space in their operating systems, besides the ocasional reserch done at Microsoft Research. The latest information being the research of another C# variant for systems programming as part of project Midori.
The Oberon community can be found at the Oberon Community Platform, hosted at ETHZ.