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
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.
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.
In many ways many Forth systems were simultaneously the programming language and the operating system, especially on small systems. Having a single integrated system meant you didn't need a lot of space, which was important when you were trying to develop software on a 1MHz system with 8KiB RAM.
There have been many operating systems written tightly integrated to a language. Oberon is one, there were several that were based on Lisp, and many Forth systems count. The early Smalltalk systems probably count as well.
I agree with you that tightly language-integrated operating systems are dead. You're absolutely right that tight integration makes it hard to change things. The tight integration could potentially save space (memory and storage), which is why I think it was more popular years ago, but that's much less relevant today. If you have tight memory constraints, you'll probably develop on a beefier system and then transmit the result to the tiny system instead, and that approach doesn't require a tightly language-integrated operating system.
> 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.
I see your point, but the Oberon system does have an ABI, it's not necessarily coupled to the Oberon language but it is coupled to the linker of the system. I have created binaries for Oberon in a rudimentary assembler, it's not hard to have them work together with the native libraries (modules). In fact it's less convoluted than ELF for example.
What I like about Oberon's module system is that there is no distinction between a library and an app or command.
In Oberon an 'executable' has 1 or more commands, somewhat similar to how git has more commands like pull, push & commit.
But everything is reusable you don't need a libgit at some point if you need support for it in another application. Neither do you need to invoke a command in a process and capture its output.
In Oberon git and libgit would be the same thing. Everything you execute as a command is directly reusable as native functional calls from other apps.
Interestingly, the same applied AFAIK to Multics - generally, as an end user, you had one process, and everything you ran in it was loadable, run-time linkable modules.
In Oberon not only is every module an application, the exported procedures are available as commands on the REPL and callable via mouse actions as well.
However in modern Windows you try to achieve a similar experience via what PowerShell allows for (.NET, COM and DLL entry points) and OLE Automation.
Still is isn't as easy and painless as the whole Oberon OS allowed to.
That's still just going one way (doing a library call in this case). In Oberon there is no distinction between a .DLL and an .EXE so to speak. A compiled module is (or can be) both.
Oberon is a gift to the computing world. It is one of the few examples of a top-to-bottom design of a full computing system (The Smalltalk Blue Book is also like this, sans the hardware).
I think the world is ready, or almost ready, for a comeback in this kind of design. Given that we have so many open, compatible standards (JSON, Office Documents/XML, hell even TCP/IP, etc, etc), the "traditional" problems of esoteric systems and their incompatibilities with each other, like we had back in the late 80s and 90s, seem to melt away. We are at a point where we can and should be experimenting with completely new systems from the ground up. Otherwise we will never get anything new, and everything will just be some iteration of Unix for the rest of time -- like medieval scholastics endlessly debating Aristotle and not discovering anything truly novel.
I liked your comment on Oberon as an example of what non-C/UNIX might look like. Your statement on language-integrated OS's implies there is a technical reason they didn't make it. It's a common mistake technologists make where they think of everything in technical aspects. Business (i.e. Marketing) and social effects are far, far, more prevalent a reason for success or failure of technologies in terms of adoption. Here's four factors that will answer lots of your questions by themselves:
1. Is it free or reduces costs in some way? UNIX on minicomputers is automatically going to get adopted if its design is useful just because of massive reductions in equipment costs.
2. Is it backwards compatible and/or does it easily integrate with the established ecosystem? IBM, Microsoft, and Intel used backwards compatible to grab markets followed by lock-in. You could say Linux/BSD eventually did with them piling more stuff on the old code. OpenBSD was the exception with them ripping stuff out. Easy example of second is languages compiling to and/or using libraries from established ecosystems like C, Java, .NET, and Javascript.
3. Is it familiar? Do they understand the concepts? And do the developers, picky about syntax, see a similar syntax? This boosted C++, Java and C# over the likes of Lisp, Prolog, or Haskell.
4. Big, dominant company pushes for X to be the language for their platform. That explains most of the big ones that are compiled and Javascript. The other factors helped, though.
These four factors are enough to absolutely kill Lisp and Forth machines in both commercial market and FOSS adoption. They don't make them impossible. They're just an uphill battle with a lot more work to do. We see communities such as Erlang and Haskell getting stronger despite being so different from established languages without being able to easily integrate with their ecosystems. Clojure [wisely] cheated by building the weird language on top of a massive ecosystem (Java platform). There's also projects aimed at Javascript trying to re-create the advantages of Lisp and Smalltalk. So, there's hope the integrated systems can make it either with lots of effort or (more wisely) just working with those factors instead of against them.
Also, it's not a big loss anyway given only a few of these integrated OS's were attempted in a big way. Over 90% of efforts fail to go anywhere. Only a handful of attempts were made. If anything, they might still be ahead of the odds in the long run. They just gotta stop creating unnecessary obstacles for themselves.
I read somewhere, that one of the political reasons why Midori failed was they tried to reboot the world and Windows team didn't like it for one second.
Similarly to how they took the whole Longhorn effort before.
At least .NET Native, async/await, span and low level memory management landed in official .NET runtimes later.
(a) wouldn't happen for most customers (esp big spenders)
(b) would throw away billions of dollars
Integrating Midori-derived technologies into Windows and using them in non-Windows applications is best move. They could still push it as a new thing they sell in parallel. Something cutting edge. They're just too afraid of losing Windows revenue.
In addition to what nickpsecurity said, I think there's another factor. Pick a language - any language. There's a lot of software that is not written in that language. I'd like to run some of it on this new OS, without having to re-write it in this OS's chosen language. If this new OS makes that difficult, well, I need that software more than I need that particular 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.
Oberon the operating system is written in Oberon the language, but the compiler compiles native code, there is no interpreter.
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.
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.
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.