A Discussion of Oberon
Written by Paul Floyd
My first experience with Oberon came after reading an article by Dick Pountain (who I admire greatly for his wonderful technical articles) in Byte about 8 years ago. I promptly FTPed a copy, and was awe-struck that a multitasking, GUI operating system and Object Oriented compiler could fit on and execute from a 3.5" floppy.
Oberon is an Object Oriented programming language descended from Pascal. And more. Oberon was developed in the late Eighties by Professors Wirth and Gutnecht at ETHZ (Zurich Technical University). (Between Pascal and Oberon, Wirth also developed Modula and Modula-2). Originally, the Oberon project consisted of building some low-cost NS32K based workstations, an operating system (also called Oberon), and the language itself. Subsequently, though it hasn't exactly become mainstream, it has evolved somewhat. The operating system has been ported to different architectures, either standalone bootable (eg PC System 3), or hosted as an 'operating environment' (eg various versions of unix, Windows and OS/2 (Oberon V4 for OS/2)). Within the Oberon operating system/environment, there has been a split between the pure and simple Version 4 and the more conventional environment of System 3. I won't dwell on the features, but some are required to understand the language a bit better. The language was also changed slightly in the early Nineties when Oberon-2 was developed (Mössenböck and Wirth).
In 1993 a spin-off company from ETHZ was founded, called Oberon Microsystems. They market a development environment called the BlackBox Component Framework (originally 1993 it was called Oberon/F) which is cross-platform source compatible between the Mac and the PC (under Windows) and retains the native look & feel of the underlying platforms. The programming language is called Component Pascal (I guess the Pascal name has better brand recognition), although it is only a slightly enhanced version of Oberon-2 (some added safety). I recently read on comp.lang.oberon that they estimate the cost of porting to a different OS at 100KDM, so I wouldn't count on there ever being a native OS/2 version.
The operating system offers all the expected basics - memory management, disk handling etc. It also performs co-operative multitasking, and windowing (in V4 the windows cannot be overlapped). One of the more peculiar aspects of the interface is that there it uses neither a command line nor an icon based metaphor. Rather, there are just a set of non-overlapping (tiled) windows in which you can type text. The windows all have enhanced text editing abilities, so you can choose font, colour etc. Applications are executed by clicking on the text name with the middle mouse button. Oberon makes extensive use of all three mouse buttons (called interclicking). If you have a 2-button mouse, there are alternatives which allow the use of the keyboard "Control" key.
Each application has one or more interface functions, all of which are entry points for that application - there is no 'main' function in the Oberon environment. As an example, consider 'Edit'. You would normally have an 'Edit Tool', which would be a text file containing the interface functions of the Edit application. When you view the Edit tool, you can click on entry points like 'Edit.Open'. This would call the Open procedure. You would also have functions like Save, Search etc. When executed, modules are dynamically linked to the kernel.
Obviously, if you are using an Oberon compiler to target the OS/2 command line or Presentation Manager environment, you can't have these arbitrary entry points, you must have a main function. This is one point where compiler writers are forced to deviate from 'Classic' Oberon.
One of the guiding principles behind Oberon is minimalism. In books on Oberon, you will see Einstein frequently quoted: "make it as simple as possible, but not simpler". I recently bought Stroustrup's 3rd edition of "The C++ Programming Language", and I noticed he used the same quote. It isn't often I get to laugh out loud when reading computer books, but to call C++ minimal in a book of nearing a thousand pages is so absurd it is comical. By comparison, the 4 Oberon books I have come to about 1300 pages, covering 2 variants of the language (with a great deal covered each time), the operating environment and a bit of the hardware. The complete language specification of Oberon-2 in EBNF fits on a single page.
It's my observation that software written in Oberon tends to be small. The original Oberon OS could fit in under 200Kbytes, and was written in 12,227 lines of code (to be exact - excluding kernel, display and floating point written in assembler). Oberon System 3 Native for PCs will easily fit on a 20Mbyte partition (OS, Internet applications, compiler and source code as well as a few general purpose utilities). At work I use a 96Mbyte Unix workstation.
Why this efficiency?
Like C++, Oberon offers the ability of code re-use through inheritance. More importantly, Oberon is so simple that re-use can be and is achieved to a high degree, something which I think is less true for C++. Combine that with compilers that will, typically, compile hundreds or thousands of lines of code per minute, and you get a very compact and responsive development environment. In contrast IBM's Visual Builder, in VisualAge C++, is virtually unusable on my aging PC.
As I said above, Wirth developed Pascal then Modula then Oberon. Pascal is a classic procedural programming language. Modula differs from Pascal in that it has modules (analogous to C++ classes). Oberon actually removed several features that were present in Modula (WITH, FOR [I said it was minimalist!], enumerated types and subrange types) but added type extension (inheritance) and type inclusion (e.g., that a SHORTINT is included in an INTEGER). Types that can be represented without loss of information by other types can be assigned without a type cast.
Oberon has no need for a definition file (header) - the compiler extracts and generates this automatically. (Note - you have to tell the compiler when the interface changes so that it may regenerate the .def file).
Oberon-2 re-introduced "FOR", modified "WITH", added type-bound procedures (these are the equivalent of methods in C++ - more on that later), and a few other changes.
The language is strongly typed, though you may use a type guard (analogous to a cast) within derived modules. Oberon has garbage collection, so you never need to delete objects created on the heap. Oberon has a module called System that allows a lot of "low level" features (shifts, rotates, etc). However, bitwise logic is very much more difficult than in C/C++ - sometimes the purist approach is taken a bit too far, I think.
OS/2 Implementations of Oberon
- Includes build environment and compiler for Oberon-2 and Modula-2. This is a commercial package, cost (when I checked) was 1800FFr.
- basic V4 + standalone exes
- Daniel Steiner
- more complete V4, WPS integration - shareware - registration was 50SFr
(I plan to write reviews of these implementations, and show a sample executable as time permits.)
References, Web pages and Books
Project Oberon - The Design of an Operating System and Compiler, (Buy)
Niklaus Wirth and Jürg Gutknecht, Addison-Wesley ACM Press, 1992,
ISBN 0-201-54428-8 548 pages hardback
(I recently spotted a copy of this at Computer Literacy, Santa Clara, whilst on a business trip).
More recently, Springer-Verlag seems to have taken up the mantle of printing Oberon books (perhaps because most development has been done in German speaking Zurich and Linz).
2 new ones (I haven't seen these):
(a bit off-topic!)
The Oberon Companion: A Guide to Using and Programming Oberon System 3,
ISBN 3-7281-2493-1, published by vdf Hochschulverlag AG
(this one may be hard to find outside of Europe! - but http://www.jfl.de/ may be the answer.)