▲ 196 points
back
93 comments
When people ask "how would you write an operating system without C?", Oberon is what I point them to. It's a very different style than Unix, in that the Oberon language is a relatively integrated part of the operating system, rather than communication being through a machine-level ABI. There were some spiritual predecessors where the compiler itself was part of the OS, and there was no other way to communicate with it than through the language semantics. I'm not completely sure whether Oberon works like that, but some Concurrent Pascal systems did. It's a very different view of what an "operating system" means.
Anyway, Oberon is a memory-safe and garbage-collected language without the pointer trickery that makes C so dangerous. So how does Oberon implement the necessary low-level parts? Fortunately, some version of the source is easily browsable online: https://people.inf.ethz.ch/wirth/ProjectOberon/index.html
Here is for example Kernel.Mod: https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...
Low-level operations are done with magical functions that simply perform an operation on a memory address identified with an integer, e.g. `SYSTEM.PUT(q0+8, q1)`. These are then presumably handled directly by the compiler (the System.Mod file does not define any PUT function). This is syntactically more awkward than the equivalent in C (`q0[2] = q1`, assuming this is an `int` pointer), but perhaps things that are unchecked and potentially dangerous should be syntactically awkward. It's not like a lot of code will be written using these facilities.
>in that the Oberon language is a relatively integrated part of the operating system
>There were some spiritual predecessors where the compiler itself was part of the OS
Sounds very much like forth or lisp to me, (and perhaps even erlang etc). Any language that's implemented like a virtual machine internally is suited to being an "integrated" operating system.
I think there's a tremendous amount of advantages to doing this as well, it reduces the levels of abstractions between the hardware and the user applications. Reduced level of abstractions means a snappier experience for the users, and also makes it easier for the developer to integrate things vertically.
http://tunes.org touches on this type of thing as well
Lisp machines, definitely. With respect to Forth, I'm not sure. Has there ever been a Forth operating system that provides the facilities we would expect of a modern operating system (and using Forth as the interface)? There are lots of Forth applications on bare hardware, and I see no reason why it should not be possible (except that you'd need some kind of extension for concurrency), I just don't know whether it has been done.
I wonder if there is a lesson in the fact that all of the tightly language-integrated operating systems are dead. While Unix is clearly tied to C at an API level, the actual ABI is entirely based on machine code, and can be accessed through any language that can produce a binary. The downside may be that tight integration hinders language innovation, in that new languages have to target the "native language", which is awkward if it is high-level. Genera (the Symbolics Lisp OS) did host some C and FORTRAN compilers ("Zeta-C", you can get it online[0]), but I am not sure how fast it ran. Unix is often disparaged for providing "mechanism" instead of "policy", but maybe that has serious evolutionary advantages.
> Sounds very much like forth or lisp to me, (and perhaps even erlang etc). Any language that's implemented like a virtual machine internally is suited to being an "integrated" operating system.
Oberon the operating system is written in Oberon the language, but the compiler compiles native code, there is no interpreter.
> Low-level operations are done with magical functions that simple perform an operation on a memory address identified with an integer,
just exactly like in C! What's the difference besides the particular syntax?
None, but in C you use the same language mechanism for following an object reference (safe in the absence of manual memory management), indexing an array, and doing crazy address arithmetic. In Oberon, safe and unsafe operations are clearly distinguished.
>just exactly like in C! What's the difference besides the particular syntax?
On that part none. But Oberon is "memory-safe and garbage-collected", so you don't use that aspect for 99% of the program (whereas in C everything is like that).
On top of that, the latest generations System 3 with its Gadgets and Active Oberon were quite good, and yes they even supported audio and video players, which made as much use of inline Assembly (Active Oberon extension) as any Windows 3.0/MS-DOS alternative back then.
Enjoy a screenshot tour, https://www.progtools.org/article.php?name=oberon§ion=co...
> When people ask "how would you write an operating system without C?", Oberon is what I point them to.
Well, you could also point them to VMS, which was deliberately designed to avoid language lock-in.
Intel/Siemens had a joint venture developing the BiiN hardware. The operating system, applications, development tools, and so on were written exclusively in Ada. However, a lot of that software fully worked on that particular chip, so when it floundered commercially that was the end of it.
"SYSTEM.PUT(q0+8, q1)"
I immediately thought of "POKE" on the built in BASIC interpreters for 80s home computers.
At the university of Antwerp they gave Oberon as the first programming language for Computer Science (back in 1997). The reasoning of the professor was so that everyone started from scratch, because nobody would know it already.
It was indeed an eye opener on how many different things there can still be. Especially the mouse key combinations that you had to press were pretty unique.
Never used it ever since that first year, but it's hard to forget because it was so different.
I was in that same class. I recall that same professor also used smurf analogies to explain programming concepts. A peculiar man.
I have fond memories of learning oberon. It gave me a deeper understanding not just of programming but the almost arbitrary conventions of popular OS’s, in where to draw the line between code, documents and applications (in oberon they were all the same thing), and how to use keyboard and mouse to manipulate items on a screen.
Was also taught in Computer Science 178 at Stellenbosch University in 1997.
> eye opener
I've never gotten around to being comfortable with mouse chording, which makes me think that it was a rather odd idea.
The Oberon programming language is also a very nice alternative to C - smaller, safer and easier to learn. It can be used without the Oberon operating system.
I think Oberon doesn't have the community to thrive though. A language nowadays is much more than the core, it's also all the libraries, tooling and tutorials around it.
That said, Oberon probably makes a very fine teaching language.
Note that lots of Nim syntax and features were inspired by Wirth's languages including Oberon and Modula 3 (https://nim-lang.org/faq.html#what-have-been-the-major-influ...)
Modula, and then Modula 2, were languages primarily written by Wirth.
But Modula 3 was a project at DEC's SRC with Luca Cardelli as the primary author.
Both Modula 2 and 3 are worth looking at, and both are fully capable systems programming languages (ie. you can write an OS using them).
Go is Oberon's and C's secret child. They met thanks to Robert Griesemer, who worked under Wirth's supervision, AFAIK, during his PhD.
I like how go gives access to the cool parts of Oberon within a relatively popular language.
This is true, but Rob Pike has his own independent connections to Oberon. Acme and other parts of Plan 9's mouse-driven UI were greatly "inspired" by the Oberon system.
Go is the secret child of Oberon-the-language and C. Before Go, Plan 9 was conceived as the secret child of Oberon-the-system and Unix.
What I like about Niklaus Wirth is that he stays true to his design philosophy and never sells out. Oberon is not a crowd-pleasing language.
Oberon is very well suited for experiments; the language is so minimal that it is quite easy to write a compiler. Here is e.g. a front end for LuaJIT: https://github.com/rochus-keller/Oberon (i.e. Oberon is used as an alternative to Lua with LuaJIT as a backend; here is more information about the project: https://medium.com/@rochus.keller/implementing-call-by-refer...).
Another interesting Oberon project I found a while ago: XOberon, an RTOS for robotics http://www.ifr.mavt.ethz.ch/research/xoberon/
No longer maintained or developed but an interesting piece of history nonetheless.
Oh man, blast from the past! Sjur the spin doctor and Roberto the master mind...
We had a collaboration where their robot was used as platform for a mid-size league robocup participant (wannabe :-})...
That realtime Oberon on PowerPC was really cool!
Far as embedded, there's also Astrobe IDE for Oberon on ARM Cortex:
To data, IMO, nothing has beaten OberonOS TUI+Gadgets for UI smoothness. (See Jef Raskin's "The Humane Interface")
Also, the Project Oberon book is a magnificent tome detailing a complete, self-contained system that was used "in production" at the University. Highly entertaining and educational.
Click here to run it in your browser on emulated hardware (no Gadgets though, too bad.): https://schierlm.github.io/OberonEmulator/emu.html?image=Ful...
Oberon+Gadgets was a glimpse into a different better world. I'm glad I got to use it enough to realize that the UI's we have are not the UI's we could have had.
The book Project Oberon is a masterpiece as are the language and system it describes.
Unrelated but related, I had a lot of fun programming in Modula-3 but it seems getting the toolchain working in 2019 is more of a DIY project?
EDIT: I can't believe I said anything that warrants downvoting. Can't we share experiences?
Mentioning Modula-3 and how to get the toolchain working isn't even remotely related to the subject. Of course we can share experiences, but it would be probably at the bottom of this thread, because it's off topic.
> isn't even remotely related to the subject
That's quite a statement, knowing the history of those languages.
> No questions are asked: this is a deliberate design decision, which needs getting used to. Most editors ask the user when closing a modified text: this is not the case in the Oberon System.
I wonder how the system deals with user errors…
For the case of accidentally closing a Viewer: The command System.Recall restores the most recently closed Viewer. Just find or type that command anywhere on the screen and then execute it by clicking it with the middle mouse button.
I prefer Inferno but Oberon is interesting. The papers aren't a bad read either.
I finds sad that many people focus too much on Plan9 and overlook Inferno, which was actually his last stop, where Plan 9 designers actually implemented some of the ideas they had originally for Plan9, like a memory safe GC userspace (e.g. Alef).
It would indeed be nice to see a comparison between Inferno and Oberon. From a distance, Alef and Limbo (the system languages used in Inferno) look like obvious predecessors to Go.
If you want to try out the Oberon language, there are several Oberon implementations for different platforms, including embedded systems, native windows executables, and the Java virtual machine: http://oberon07.com/compilers.xhtml
I feel not having anything on a runnable state from System 3 or AOS doesn't do proper justice to Oberon.
Those versions were already quite close to something like NeXT, but with Oberon variants.
Nowadays what is left are random ISOs that don't always boot properly on VMs and it isn't easy to compile the those OSes, even with some source still floating around on Github.
EDIT: Some System 3 and AOS links from here might still be useable, https://en.wikibooks.org/wiki/Oberon#System_Variants
I love the idea of smaller more logical operating systems. I am surprised that in the era of giant tech companies with top programmers and a lot of resources the most commercially viable strategy is still "try and paper over the complexities of linux" instead of starting something smaller and more modern.
When the CPU's developer manual is 2198 pages and still growing, any option other than starting with Linux and trying to keep up (i.e. VT, SGX, TPM, GPU, etc) will be extremely costly.
https://www.intel.com/content/dam/www/public/us/en/documents...
These things like Oberon and Inferno are from a more innocent era of computing.
I think that Intel’s cpu complexity (and arm and for that matter RISC v CPUs) is that they are designed to speed up existing software. Software that was written 50 years ago on simpler machines. Starting from scratch is not as complex as you might think if running existing software at “native” speed isn’t a requirement.
> starting something smaller and more modern
Where do you draw the line? Do you throw away Linux and write your own OS, which is bound to grow to the same level of complexity because it needs to deal with hardware complexity? Or do you throw away the existing hardware as well and start from silicon? Maybe even reboot the computing stack on an entirely different type of hardware?
I would be so down for a risc-V laptop running redox
The problem of starting again becomes harder with each passing year because you have more hardware to support, more complicated software that needs porting and higher expectations from users about what a modern OS should behave like.
It’s a similar problem with creating new web browser rendering engines.
I've been considering doing this for Snapdragon SOCs. I'd probably start with the 855 or the 8cx and not worry about any backwards compatibility with anything other than the latest and greatest hardware.
Oberon! The king of the faeries!
If I remember correctly, Wirth mentioned the moon Oberon and the fact that the name starts with an "O" (like "object oriented") as the source for the name of his programming language.
Somewhat off topic: this wikipedia page reads like a sales pitch. Does anyone know how to flag such pages for attention?
Comment on the associated talk page, or edit it yourself to make it better?
https://en.m.wikipedia.org/wiki/Wikipedia:NPOV_dispute may be relevant as well.