- #How to get the oberon system software
- #How to get the oberon system code
- #How to get the oberon system free
You could say Linux/BSD eventually did with them piling more stuff on the old code. 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.
#How to get the oberon system free
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.Ģ. Here's four factors that will answer lots of your questions by themselves:ġ. Marketing) and social effects are far, far, more prevalent a reason for success or failure of technologies in terms of adoption. It's a common mistake technologists make where they think of everything in technical aspects. Your statement on language-integrated OS's implies there is a technical reason they didn't make it. I liked your comment on Oberon as an example of what non-C/UNIX might look like. 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. 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. You're absolutely right that tight integration makes it hard to change things. I agree with you that tightly language-integrated operating systems are dead. The early Smalltalk systems probably count as well. Oberon is one, there were several that were based on Lisp, and many Forth systems count. There have been many operating systems written tightly integrated to a language.
#How to get the oberon system software
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. In many ways many Forth systems were simultaneously the programming language and the operating system, especially on small systems. It was discussed on Hacker News in 2016: Unix is often disparaged for providing "mechanism" instead of "policy", but maybe that has serious evolutionary advantages.Ĥos was an operating system written in Forth. Genera (the Symbolics Lisp OS) did host some C and FORTRAN compilers ("Zeta-C", you can get it online), but I am not sure how fast it ran. 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. 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 wonder if there is a lesson in the fact that all of the tightly language-integrated operating systems are dead. 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.
#How to get the oberon system code
It's not like a lot of code will be written using these facilities. This is syntactically more awkward than the equivalent in C (`q0 = q1`, assuming this is an `int` pointer), but perhaps things that are unchecked and potentially dangerous should be syntactically awkward. These are then presumably handled directly by the compiler (the System.Mod file does not define any PUT function). Low-level operations are done with magical functions that simply perform an operation on a memory address identified with an integer, e.g. So how does Oberon implement the necessary low-level parts? Fortunately, some version of the source is easily browsable online: It's a very different view of what an "operating system" means.Īnyway, Oberon is a memory-safe and garbage-collected language without the pointer trickery that makes C so dangerous. I'm not completely sure whether Oberon works like that, but some Concurrent Pascal systems did. 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.
![how to get the oberon system how to get the oberon system](https://i.ebayimg.com/images/g/YIAAAOSwSxtdwCjf/s-l640.jpg)
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. When people ask "how would you write an operating system without C?", Oberon is what I point them to.