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.

Native Oberon

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.

Native Oberon System 3 and Gadgets

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.

Active Oberon System

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.

Update 30.11.2019: There is now an updated language report that you can retrieve from current website, the new version is not yet final and there is an ongoing discussion on the forums.

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.

Installing AOS

There are some ISO image available at Oberon Community Platform, which gets some occasional updates.

The ISO images can be downloaded from

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:

AOS Boot Screen

Starting the installation

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.

AOS Installer
Selecting the target disk

Packages Selection

As in any modern operating system installtion, there is a set of packages to choose during the installtion process:

Selecting which packages to install

Installation Confirmation

Before the installation can proceed, the set of desired selections needs to be confirmed:

Installation confirmation

Installation Progress

Afterwards a progress dialog gets displayed:

Installation confirmation

Installation Done

Until the finish installation message is finally displayed:

Installation confirmation

After a reboot, it is then possible to start using the AOS operating system.

Available Applications

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.


File Manager

How to navigate the set of existing files and directories.

File manager

The original filesystem has a flat structure, however additonal filesystems can be pluggable via modules.

CD Burner

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:

CD Burner

Available disk operations:

CD Burner


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.



Partition Manager

In a operating system designed to share the hardware with other systems, a way to partition the
hard disk is always handy.

Partition Manager

Performance Monitoring

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:

Object Tracker


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:


Oberon System 3

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.

Oberon System 3

The screen shows a typical Oberon System 3 session, with a text editor open, log pane and several tool panes.

Developing AOS Applications

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.

Programmers Editor

GUI Editor

The GUI Editor eases the work of creating graphical interfaces for applications, similar to RAD tooling available in other languages.

GUI Editor


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.

Current State

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.

Update 30.11.2019: As referred above there is an Active Oberon community still pushing the language forward and an updated language report is in the process of being released with several new features. Also Joe Duffy has produced a series of blogs describing what the research he was involved was all about, Project Midori.


The Oberon community can be found at the Oberon Community Platform, hosted at ETHZ.

There is a Telegram channel to discuss Active Oberon themes.

Several active Oberon compilers can be retrieved from A resource for the Oberon-07 language web site.