back to article The wild world of non-C operating systems

Believe it or not, not everything is based on C. There are current, shipping, commercial OSes written before C was invented, and now others in both newer and older languages that don't involve C at any level or layer. Computer hardware is technology yet very few people can design their own processor, or build a graphics card. …

  1. heyrick Silver badge


    There's some bits written in C. Some.

    But the system API and the huge majority of, well, everything is hand crafted ARM code.

    Start here (main OS startup, after HAL init).

    1. bombastic bob Silver badge

      Re: RISC OS

      As I recall, RT-11 (Dec PDP-11) is also written entirely in assembler. It's quasi-open-source in that you can compile in your own device drivers along with the standard ones. As a runtime OS it was designed to control equipment and so i understand that the 'Unibus' and 'Q Bus' architectures were designed with custom peripheral boards in mind. RT-11 had foreground and backround capability and with memory management hardware, could swap blocks of memory in and out of visibility. Anyway, experiment with simh if you are so inclined (I have). Built the kernel a couple of times from source even, making fixes here and there for various things. But some of the userland programs may have been written in FORTRAN or some other lingo. Still kinda fun to toy with. And then when you see PDP-11 op codes doing post-increment and pre-decrement you can easily see how that ended up in the C language.

      1. Jonathan Knight

        Re: RISC OS

        I started my computing career on a DEC-10 which was all written in Macro-10 assembler and that had shared libraries within an application (HIGH SEG). Then it was a mixture of CPM on a RML380Z, whatever the PET ran, BBC Basic and a very early Microsoft Basic on a Challenger II

        I used RSTS/E back in the early 80's and most of the core tools were written in DEC Basic-Plus with the low level kernel in Macro-11 assembler. It also had shared libraries.

        Then OS4000 all written in Babbage for the start of my University degree where I finally met the first Unix and so the first OS written in C, some 10 years after I started using computers.

        I guess the C centric OS view really only works for the youngsters.

    2. Chairman of the Bored

      Re: RISC OS

      Thanks for the link.

      Lovely code. I've not done Arm ASM - only Intel 8051 and 80186 - but the code is easy to follow. The authors seem to have hit a good balance between providing useful information and verbosity.

    3. Torben Mogensen

      Re: RISC OS

      RISC OS is an impressive bit of software, but the fact that it is written in 32-bit ARM assembler (which was a somewhat sensible decision back in the 1980s, when it was written) makes it a dead end. It can't even run on the 64-bit-only ARM variants, which are becoming increasingly common.

      AFAIR, RISC OS was not Acorn's first go at an OS for their ARM-based machines. There was a project written in (IIRC) Modula2, but that was far from ready by the time the first Archimedes computer hardware was finished, so Acorn made ARTHUR (some jokingly said it was short for "ARM OS by Thursday"), which took many elements from the OS from the BBC Micro (which was written in 6502 assembly language) and added a very limited GUI. This was after a year or so replaced by RISC OS, which was clearly an extension of the code used in ARTHUR. After another year (about 1990, IIRC), this was upgraded to RISC OS 2, which had many advanced features that would not appear in Windows until Win95, and some that haven't made it there yet. At the time I loved it, but in spite of an active fan base, it will not have a long-term prospect unless rewritten in a high-level language that can be compiled to multiple platforms. Rust would be ideal, but it is probably hard to retrofit RISC OS to the Rust memory model. Maybe it is better to write a new OS from scratch that takes the best elements of RISC OS and adds support for new stuff such as multicore processing and UNICODE.

      1. heyrick Silver badge

        Re: RISC OS

        RISC OS 2 followed Arthur, and the advanced one was RISC OS 3.

        Yes, it was fairly common to write stuff in assembler back then, but in this day and age it limits you to compatible processors. Thus the only two options are either to devise some sort of emulation to carry on running it as it is, or to recreate something new that uses concepts of what made RISC OS unique.

        Pretty much the entire underlying API would need to be thrown out, though. It is based around the behaviour of the ARM's SWI instruction, which is unlikely to map onto other sorts of processors. Time, perhaps, for something a little less bare metal?

        The proposed original OS was ARX, I think it was called. Needed a 4MB machine and a harddisc and started swapping after no time. Could have been impressive a decade later, but was a complete dead end in 1987. Look at the prices of harddiscs and memory back then.

        RISC OS, on the other hand, could manage a rudimentary but functional DTP package on a 1MB machine.

  2. UCAP Silver badge

    Apollo OS

    The old Apollo workstations & servers during the 1980'2 (before Apollo has absorbed by HP) ran an OS that was written in a a version of Pascal. In incredible system; at one time we ran up a lab of about 20 diskless nodes from a single disked workstation with no appreciable performance headaches.

    1. Graham Cunningham

      Re: Apollo OS

      I started work at TI in 1985 and was absolutely wowed by Aegis running on a few B&W DN320s and colour DN660s. With optical mice on checkered aluminium mouse pads, as I recall. Quite a step up from my BBC model B.

      8-inch floppies ftw! ;)

    2. MarkMLl

      Re: Apollo OS

      I believe that Cray also used Pascal-based OSes. However I'd caution that it's likely that the implementation language was a long way from (standard) ISO Pascal or (de-facto standard) Turbo Pascal, in the same way that Burroughs' implementation language for the MCP (ESPOL) was distinct from the ALGOLs that they used for application programming.

  3. Warm Braw

    Multics & PL/I

    Multics was written in (a version of) PL/I with the added challenge of having to develop the compiler in parallel with the operating system.

    IBM has written chunks of its various operating system using PL/S and its successors.

    VAXELN, a bit of a curiosity in the Digital Equipment Corporation range of operating systems, was written in Pascal. Chunks of VMS were written in BLISS-32 (though a lot of it was Macro-32).

    1. Andy E

      Re: Multics & PL/I

      I actually wrote extensions to VMS in Macro-32 before switching to Bliss-32 after a training course.

      This was of course many, many years ago......

      1. Anonymous Coward
        Anonymous Coward

        Re: extensions to VMS

        Yep. I wrote a new OS Directive in Macro-32 after attending a Kernel & Device driver course. IT would give the user full system privs if you executed a program that called it.

        Yes, I know that it was a huge great security hole but I only ever installed it on a machine that was used for testing. I just wanted to prove that it could be done.

        1. bombastic bob Silver badge

          Re: extensions to VMS

          DEC operating systems at that time were not the most secure. RSTS/E had a program called 'init' that would often be publically runnable and (necessarily) with the privilege bit set. As a college student I experimented with it and discovered that you could send it commands like "LOGIN KBxx" and it would log KBxx in with whatever account you specified, and NO password required. Ooops. Ginormous security crater built right in. (this program runs the RSTS/E startup sequence - another simh exercise and you'll see it in action - somewhere there is an RSTS/E image you can DL and run under simh, i found one)

          A lot of RSTS/E was written in BASIC and compiled into a kind of P-code. But I am pretty sure the kernel was done in the MACRO assembly language.

    2. coconuthead

      Re: VMS

      When DEC ported VMS from the 32-bit CISC VAX architecture by 64-bit RISC Alpha, they wrote a compiler to translate the MACRO assembly language into native Alpha machine instructions, treating it as a high level language. (Some of it even had block structure, using the powerful macros that the assembler did indeed have.)

    3. Fred Goldstein

      Re: Multics & PL/I

      Remember the earlier DEC OSs from the 36-bit world. TOPS-20 was based on BBN's TENEX, which was of course written in BCPL. That was a nice OS, user friendly and powerful.

    4. Steve Graham

      Re: VMS

      Our VAX 11/780 came with a complete set of source code... on microfiche. I spent many an hour studying the BLISS and Macro. (Many files signed by the legendary Dave Cutler.)

      The VAX instruction set is probably the most elegant CISC set that I've ever programmed in. The National Semiconductor 32000-series was directly inspired by it, so I've always thought that it was a pity that the bastard x86 won.

      1. Michael Wojcik Silver badge

        Re: VMS

        Ah, VAX assembly. All those handy CISC opcodes, and the system macro libraries... I had a school assignment where we had to use a macro (SYS$UNWIND or something like that?) to implement exception handling. Very cool.

        The VAX assembly course tied with the LISP and Scheme courses for being the most fun just to write code.

    5. Michael Wojcik Silver badge

      Re: Multics & PL/I

      IBM has written chunks of its various operating system using PL/S and its successors.

      Yep. IIRC the VMM (monitor) that underpinned AIX 2 on the RT PC was written in PL/M, and the OS/400 kernel in PL.8 (which used the "." rather than "/" in its name for some reason). PL/I variants were all the rage at IBM for a while.

      1. Peter Gathercole Silver badge

        Re: Multics & PL/I

        I think it was "VRM", or Virtual Resource Monitor or Manager.

        VMM is the Virtual Memory Manager from AIX 3.1 and later, and is definitly part of AIX,

        VRM was a very interesting abstraction layer that presented AIX a full 32 bit address space, even though the RT maxed out at around 24MB (I think, it's a long time ago). This meant that AIX did no paging itself, and any that happened was actually done by the VRM.

    6. Deryk Barker

      Re: Multics & PL/I

      Multics was the best, most influential OS ever written and I still miss it.

      If you are interested there is now an emulator for the DPS8M mainframe it ran on and you can run Multics on that (it took all of 5 minutes to download and get running).

      There was indeed no PL/1 compiler in existence when the project started and the company that was contracted to supply one were extremely late, so a subset (EPL for Early PL/1) was created and Multics written in that before the first full compiler was finished. I forget which version (I think maybe the V1 PL/1 compiler) was up and running before IBM even had a compiler in alpha test.

      Eventually the V2 PL/1 compiler was complete and was a full implementation of the language and arguably the best PL/1 compiler on any system. It was generally reckoned back in the early 80s that it produced more efficient object code than anyone but the very best assembler programmers could produce.

    7. Steve Channell

      Re: Multics & PL/I

      No discussion of operating systems is complete without a reference to Multics :)

      It was Multics and MVS usage of PL/1(S) that persuaded Intel to adopt PL/M

  4. Steve Davies 3 Silver badge

    What about Assembly Language?

    Some notable OS's have been written in Assembler but tend to get forgotten.

    My personal favourite is RSX-11-M/M-Plus/S

    I had great fun modifying the boot code for 11S so that some extra custom features were enabled. Those were the days when IT was fun and there was always something new happening.

    1. itzman

      Re: What about Assembly Language?

      Fairly sure MSDOS precedes 8086 C and was written in assembler, as was CP/M...

      1. Mage Silver badge

        Re: What about Assembly Language?

        Yes, MS-DOS was a bought in reverse engineering of CP/M 86, which was assembler. Much of CP/M 86 and CP/M 86 or DOS Apps were auto translated from 8080 code to 8086 by an Intel tool. The 8088 / 8086 was really a superset of 8080, hence the awful 64K segments and no 16 bit flat addressing like all the true 16 bit cpus in early 1980s.

        Early C was barely more than a Macro assembler and the most common C bugs where/are

        Unexpected expansion of the macros

        Array bound violation because no compile or runtime checking. purely null terminations. Both Modula-2 and VB6 had a far better way of doing strings. C++ also had a better way of doing strings from about 1988, but mostly ignored.

        Libraries buggy or misunderstood.

        No strong typing, issues with parameters, inappropriate casts (Solved and ignored in C++, solved better in Modula-2).

        Inappropriate use of pointers (dereferencing pointer to unallocated RAM, arithmetic etc).

        Big failing of C++ was AT&T's insistence on backward compatibility. Strustrupp didn't want it and it's been crippling since.

        1. Dan 55 Silver badge
          1. Falmari Silver badge

            Re: What about Assembly Language?

            @Dan 55 I wholeheartedly agree.

            Thanks for the video link, where he talks about code from 1996 made me smile we still have code from 1995 in our codebase. Which have been compiled nightly through multiple iterations of our c++ compiler without requiring change.

            But when changes have to be made (not because the C++ version is newer) in code that has not be touched in over 20 years you are totally on your own as none of your workmates have a clue about it.

        2. Roland6 Silver badge

          Re: What about Assembly Language?

          >The 8088 / 8086 was really a superset of 8080, hence the awful 64K segments and no 16 bit flat addressing like all the true 16 bit cpus in early 1980s.

          Blame the IBM PC which used the Intel 8086 in preference to Motorola or National Semiconductor (who's architecture and instruction set was perhaps the best of the three), and the rest is history.

          1. Chris Gray 1

            Re: What about Assembly Language?

            Nitpick! Nitpick!

            The IBM PC used the Intel 8088, not the 8086. The 8088 had 8-bit data busses so that it was compatible with all the existing 8-bit peripheral chips.

            1. David 132 Silver badge
              Thumb Up

              Re: What about Assembly Language?

              You are technically correct. The best kind of correct.

            2. Roland6 Silver badge

              Re: What about Assembly Language?

              Agree you are technically correct: the 8088 was the 8-bit 8080 chipset compatible version the 8086.

              Funny to think that back then the upgrade from 8-bit to 16-bit architecture was as big a jump in circuit board complexity and cost as moving from 16 to 32-bit and then 32 to 64-bit.

              However, the point is IBM chose Intel...

          2. Peter Gathercole Silver badge

            Re: What about Assembly Language?

            Although the Motorola 68000 was available around the same timeframe as the 808x processors from Intel, the corresponding peripheral chips weren't. And the 68008 (used in the QL), which allowed the use of some 6800 peripheral chips was a few years later still.

            The team creating the IBM PC were trying to work under the covers, because the IBM leadership were worried about a functional desktop computer undermining the sales of their other systems. So the PC team were not able to leverage IBM's name to make chip suppliers change their delivery schedules.

            As a result, they went with the 8088, which allowed them to use a lot of existing, off the shelf 8 bit peripheral suport chips from both the 8080 and Z80 families, which were available, cheap, and widely understood. And you have to remember that the systems they thought they would be selling against were the Apple ][ and it's follow up systems.

            It made sense to them at the time, even though in hindsight it was the wrong decision.

      2. Anonymous Coward
        Anonymous Coward

        Re: What about Assembly Language?

        Of course early C compilers and interpreters were also coded in assembly, which was still pervasive for another couple decades. And why not? It was useful to have a portability layer, but those layers didn't strictly NEED to be implemented portably themselves.

        Assembly is still useful to know, but a bit masochistic if you are not hacking away at bits of existing code, or flashing chips IMO.

        1. Anonymous Coward
          Anonymous Coward

          Re: What about Assembly Language?

          "early C compilers and interpreters were also coded in assembly".

          Nope. The earliest C compilers were written in C. It's possible, but highly unlikely, a few masochists chose to write these in assembly because they didn't know any better.

          Read this article by the bloke who invented the language (amongst one or two other things):

          1. A.P. Veening Silver badge

            Re: What about Assembly Language?

            The earliest C compilers were written in C.

            The first C compiler must by necessity have been written in something different than C.

            1. MrReynolds2U

              Re: What about Assembly Language?

              Agreed, otherwise it's a sort of immaculate conception compilation.

              I think C is brilliant but it's not quite that clever, shirley?

              1. dcsprior

                Re: What about Assembly Language?

                Well, you could theoretically write the first compiler in C, and "run" it step by step (for the compilation of itself) with brain, pen and paper.

            2. martinusher Silver badge

              Re: What about Assembly Language?

              Not strictly true. If you think of C as a sort of upscale macro assembler then you can bootstrap C by writing assembler macros. This was the way that the original compilers were made -- implement a subset using whatever means were to hand and then use that subset to implement a more complete compiler. Rinse and repeat until you have the complete compiler.

              Once you've got Compiler Version One then its straightforward.

            3. Michael Wojcik Silver badge

              Re: What about Assembly Language?

              Whether that's necessary depends on your definition of "compiler".

              You write a minimal compiler in a subset of C for the same subset of the language, hand translate that to assembly — it can be quite straightforward — and assemble that.

              That bootstraps the minimal compiler. Compile it with itself and confirm the assembly it produces is valid.

              Now add more features, still using the subset in the compiler itself, and compile it with itself again. And so on.

              Is the human who translates the initial compiler also a compiler? Or do you use that term only for a program? It's a question of definition, and people disagree. But you certainly don't need to create a compiler for the entire C language in assembly or some other HLL in order to create your first C compiler. You can start with a very small subset of the language. If you're willing to allow certain deviations from the standard, you can start with even less.

              Then, of course, once you have a working compiler you can split it into a portable front end and just write the code generator for each new platform, as first pcc and later GCC did (as well as various others).

            4. ssokolow

              Re: What about Assembly Language?

              I believe it was initially written in "New B", which was written in B.

              I can't remember whether B had its own bootstrap compiler written in assembly or relied on BCPL for that, but I think it did because, from my hazy memories of what I read, B was created to fit a BCPL derivative into the cramped memory of the PDP-7.

              1. Anonymous Coward

                Re: What about Assembly Language?

                First B compiler was written in TMG. Was then rewritten in B. TMG I think was implemented in assembler.

            5. Peter Gathercole Silver badge

              Re: What about Assembly Language?

              The first C compilers were written in BCPL.

        2. Jaybus

          Re: What about Assembly Language?

          You do realize that every OS has bits written in assembler, yes? For example, the entire arch directory of the Linux source tree. This is because there are ISA features, particularly supervisor-mode instructions, for which the high-level language has no matching construct. There are still many hardware features that aren't implemented in the language, but are rather handled by intrinsic functions, for example SIMD instructions. So, actually it is still ESSENTIAL to know, at least for those not working exclusively with user-mode code.

      3. J.G.Harston Silver badge

        Re: What about Assembly Language?

        Wasn't CP/M written in AP/L? (A Programming Language) The disassembled code certainly shows evidence of not actually having been written in assembler, with lots of weird coding patterns.

        1. Chris Gray 1

          Re: What about Assembly Language?

          I don't see any indication of intended humour, so I'll feed the troll...

          APL is darn near the highest level of the programming languages from long ago. One character to multiply matrixes. (OT: I worked with Ken Iverson's nephew for a few years.)

          I also wrote a RAM disk driver for CP/M. You do that by taking the assembler source to the existing disk driver for your system and modifying it as needed. I don't recall if the assembler source for the rest of the system was available from Digital Research or not.

        2. IvyKing

          Re: What about Assembly Language?

          CP/M was written in PL/M, which was suggests it was developed to be a micro-computer version of PL/1. The original PL/M compiler was written in FORTRAN and the source code had been put i the public domain a few years ago.

          A lot of early MS-DOS applications were written in Pascal, with the compiler running on a VAX - remember a review of a circa 1982-83 MS Macro Assembler where the reviewer said it seemed to be more Pascal oriented than 8086 assembly code oriented.

          The 8086 was designed to make it easy to translate 8080/8085 assembly language to 8086 assembly language. The 8080 was designed to be make it easy to re-use 8008 source code, so the latest and greatest intel processors are still carrying baggage from the 8008 announced in 1972.

          1. 42656e4d203239 Silver badge
            Thumb Up

            Re: What about Assembly Language?

            >>the latest and greatest intel processors are still carrying baggage from the 8008

            Wasn't the 8008 an 8 bit version of the 4004? So the baggage actually comes from an even more ancient CPU... though I did read once that the 8008/4004 microcode has been expunged from modern Intel CPUs.

            This approach (maintaining old tech in newer iterations) isn't limited to CPU design though - I learned that Mitel MCD (as it was called when I was installing it) was actually a wrapper around a virtualisation of their earliest (physical hardware) switch - the hardware worked so why change it? convert it to a VM and what could possibly go wrong...

            That approach explained the programming interface bacially being a kermit session to the now virtual hardware... which made replicating programming between remote switches rather pedestrian.

          2. J.G.Harston Silver badge

            Re: What about Assembly Language?

            That's the bunny. The old forgettery playing up. Programming Language for Microcomputers.

        3. MarkMLl

          Re: What about Assembly Language?

          No, but Kildall had APL experience from his time at Washington

          He also had Burroughs mainframe experience, so he was well aware of the feasibility of writing an OS in a high-level language.

    2. bazza Silver badge

      Re: What about Assembly Language?

      From the article:

      This is not intended to be a comprehensive list. There are too many such efforts to count, and that's even with intentionally excluding early OSes that were partly or wholly written in assembly language.

      I think they know about them (and so do we now, thank you!), but them there presses were sitting impatient to go.

      1. David 132 Silver badge

        Re: What about Assembly Language?

        > but them there presses were sitting impatient to go.

        Which meant, sadly, that they had to drop the dead donkey.

    3. Graham Cobb Silver badge

      Re: What about Assembly Language?

      My first job after graduation was doing RSX-11M/M+/S kernel software development in PDP11 assembler for DEC's small development team in the UK. Fortunately, after a year or so I moved to VMS kernel code - not only was MACRO32 much more powerful than MAC11 but almost all new VMS kernel development was happening in BLISS32 by then.

      However, my first programming job (in my year off before university) was in APL! Now there was a unique language. Although that wasn't kernel code.

      1. UncleDavid

        Re: What about Assembly Language?

        Doing a job at Lloyd's of London I had to make some changes to the RSX-11/M scheduling fundamentals to support the transaction processing efficiently, but we asked Reading to make the change to allow parallel seeks on a bank of disk drives. Was that you?

    4. Liam Proven (Written by Reg staff) Silver badge

      Re: What about Assembly Language?

      The piece was getting overlong as it was, so I made a conscious decision to omit things written in assembly language. Any assembly language. There are just too many of them.

    5. David 132 Silver badge

      Re: What about Assembly Language?

      >Those were the days when IT was fun and there was always something new happening.

      Such negativity. Why, these days after decades of research and hard work we have mandatory activation, always-on DRM, the ability to patch applications and OSs whenever the developer feels like it without having to wait on the pesky user... almost every day, we get a whole new radical paradigm in UI design, whether it's flat, flatter, monochrome, greyscale, slightly-less flat... heck, we've even managed to accelerate and streamline applications by renaming them "apps". What's not fun about all that, you cynic??

      Have a beer and join me building my time portal back to about 1992, won't you?

  5. Anonymous Coward
    Anonymous Coward

    Modula 2

    Wow, some memory from my Amiga years. I'm sure I spotted a modula 2 compiler in my tools library !

    What about Prolog ? It was weird and fun, although I don't remember it to be useable outside of solving puzzles ...

    1. bazza Silver badge

      Re: Modula 2

      An OS written on Prolog would just be, well, "diseased" is the kindest word I can think of!

      1. Arthur the cat Silver badge

        Re: Modula 2

        An OS written on Prolog would just be, well, "diseased" is the kindest word I can think of!

        Take a look at the Japanese Fifth Generation project. The idea was that the resulting machines would run Prolog natively.

        I was at the conference in Bristol in the early 80s when they did their big presentation over here, and got to talk with the people who'd actually be doing the research(*). I was fairly cynical about the idea so asked them if they thought it would work. Their reply was on the lines of "Who cares? We've got 5 years of big funding and will get another 5 years unless we totally screw up in the first 5. It's a government initiative so will never be deemed a failure."

        (*) As opposed to the nominal heads who were basically political academic players and government placemen, and too busy glad-handing their UK and European opposite numbers to speak to low-lifes like me.

        1. Roland6 Silver badge

          Re: Modula 2

          >The idea was that the resulting machines would run Prolog natively.

          Back in the 80's people weren't so fixated on one chip architecture, so you had chip designers building chips to support hihgh-level languages including the "AI" languages which naturally had a different architecture to chips designed to run conventional languages like C.

          Obviously, if you look at the development of the Intel x86 family you see in each generation it provided better support for structured stack-oriented procedural languages (i186), OS's (i286) etc.

          Linking to the related article on C and Rust/Swift, it would seem that Rust/Swift et al need to get closer to the chip and ensure the silicon and microcode directly supports key language features.

          1. SCP

            Re: Modula 2

            "Back in the 80's people weren't so fixated on one chip architecture, ..."

            And for those too young to have been there - a case in point was the Transputer and Occam from Inmos.

            1. Arthur the cat Silver badge

              Re: Modula 2

              At that same 80s conference I got to tour Inmos' facilities. The Transputer was a nice idea in its own way.

              1. Roland6 Silver badge

                Re: Modula 2

                >The Transputer was a nice idea in its own way.

                As was wafer-scale integration.

          2. Michael Wojcik Silver badge

            Re: Modula 2

            Rust is about as close to the metal as C is. It just imposes more restrictions on the programmer, and provides more syntactic sugar and abstractions at the library level. But it runs comfortably in the same environments as C does.

            For an OS, the reduced need for serialization of execution provided by Rust's object-ownership guarantees (which are imposed at build time, not run time) should overcome any incremental overhead introduced by good Rust programming practices.

            For end-user applications, any performance difference is almost certainly irrelevant, because the vast majority of them will be I/O-bound.

            For stuff in the middle -- execution environments and libraries and subsystems and whatnot -- some of it will be CPU-bound and performance-sensitive, but again most of those things will get more back from the reduction in locking than they'd lose from Rust's level of abstraction, which is not, after all, much higher than that of C, much less that of C++.

        2. MarkMLl

          Re: Modula 2

          However there's little reason to assume that an OS written in Prolog would actually /reason/ about what needed to be done to e.g. service an interrupt, rather than using an imperative extension to the language intended for systems programming.

    2. Anonymous Coward
      Anonymous Coward

      Re: Modula 2

      Fucking Modula 2. It's soooo close to Pascal, but there are little quirky differences, you know? In the early 90's, I was doing anything and everything in TurboPascal on DOS. It was my mother tongue and I had near total mastery of the language. Then in the mid 90's, I took two Modula 2 classes at Uni, and that was enough to corrupt my previously pristine Pascal knowledge. Suddenly my old Turbo friend was making hurtful comments about my code, implying I had done something syntactically wrong, and refusing to compile. It was that bloody Modula 2 that had wormed its way into my brain, and would peek-out at unexpected times and places in my code. I never did fully recover from that and wound up chained to the VB grindstone for a couple of years.

      I mean, Module 2 is a great successor to Pascal, but it does make things harder if you try to go back to Pascal.

      1. Anonymous Coward
        Anonymous Coward

        Re: Modula 2

        I remember Modula-2 as being like C with Pascal warts grafted on. It wasn't bad, certainly better than pure Pascal.

        1. Marco van de Voort

          Re: Modula 2

          Other way around. It was Pascal with some C warts (like << >> for shift operators and case sensitivity) grafted on.

          It was also what stronger typed than either, mixed type expressions needed to be disambiguated with casts/conversions.

      2. Julz

        Re: Modula 2

        Hum, Modula 2 was Pascal done proper. Real I/O and the ability to pass functions (and other stuff) as arguments, plus a whole load of cleaning up of the syntax. One of my favorite languages. What do we (almost) all use now, Oh, yes, pathetic Java script and PHP; the twins from hell. Now there's progress...

        1. Marco van de Voort

          Re: Modula 2

          The block structure of Modula-2 is still my favorite. NO begin or { except for function and module level blocks. A minor flaw was that the adding of the function/module name to function/module END keywords. That made refactoring needlessly complicated and setting them apart for better error generation could also have been achieved with END function/module.

          My main grudge was the lacklustre string support. It was as bad as C. Static arrays or pointer to chars via a library construct. Ugh. Fine for embedded work, but for anything up the application tree, it was cumbersome

        2. MarkMLl

          Re: Modula 2

          I agree. Basically, Pascal was a rush job designed in between April when Wirth threw his toys out of the pram and resigned from the ALGOL-68 committee and the intake of new graduates in the Autumn.

          But it made too much of a splash, and Wirth was never able to really popularise the "done right" version that was Modula-2.

          What is not generally known is that Borland had an 8-bit Modula-2 that they decided not to sell themselves but licensed to IIRC Echelon (Ciarcia's company). However they didn't license the documentation, which meant that it was essentially unsellable.

          The 16-bit implementation became TopSpeed, published by JPI and later Clarion.

      3. MarkMLl

        Re: Modula 2

        Yes, but if you look at Post-Wirth Pascal you'll find that just about everything that's been added is basically Modula-2 syntax, e.g. the try-finally-END and try-except-END blocks.

    3. keithpeter Silver badge

      Re: Modula 2

      Wasn't there an airline booking system written in prolog? I once had to help some travel and tourism teachers get the official training system working on green screen dos boxes decades ago.

      Serious manuals and widely used I recollect (FE college)

      1. R Soul Silver badge

        airline booking systems in prolog

        Wasn't there an airline booking system written in prolog?

        I'm sure at least one of them still exists, according to my recent experiences booking BA flights.

    4. Liam Proven (Written by Reg staff) Silver badge

      Re: Modula 2

      Windows NT 3.1 - 4 devised and built the configuration of the network stack using an embedded Prolog interpreter.

  6. Mage Silver badge

    Jupiter ACE

    It ran Forth Programs on a Z80, but I don't know what its minimalist OS was written in.

    I wrote an almost OS in Modula-2 for x86 to run a Game engine. It only used DOS to load and had simple co-operative multitasking using coroutines. I wrote drivers in M2 for keyboard, CGA, Hercules, EGA, VGA, soundblaster PCM & MIDI and audio on PC speaker. It could do MIDI music, sound effects on PC speaker, SB audio, scroll background, move foreground tiles, animate sprites, multi-key input and read HDD all at the same time. Performance as good or better than assembler coded games. Though only using 8086 compilation it needed at least IBM AT compatible hardware rather than XT for various HW timers, DMA etc.

    Sadly getting artwork done was too much work.

    1. Arthur the cat Silver badge

      Re: Jupiter ACE

      It ran Forth Programs on a Z80, but I don't know what its minimalist OS was written in.

      Forth is a minimal OS in its own right usually. That's how it started out.

      1. Mike 125

        Re: Jupiter ACE

        It was, and probably still is used to control large telescopes.

        And the BBC micro had a full fledged version:

        These guys still support it with some high quality, native compilers:

    2. Dan 55 Silver badge

      Re: Jupiter ACE

      I don't know what its minimalist OS was written in.

      In Z80 assember, like its Sinclair cousins.

      I say cousins because it was designed by Richard Altwasser (hardware) and Steven Vickers (software) after they finished working for Sinclair.

      1. Anthropornis

        Re: Jupiter ACE

        Having dumpled my ACE's ROM back in the day, much of the higher-level OS was of course written in FORTH. That was the thing about FORTH - write some small part in assembler and then leverage that.

    3. Tom 7

      Re: Jupiter ACE

      The Dragon32 had a Forth OS IIRC . Small, tight fast and with a complete lack of software.

    4. Chris Gray 1

      Re: Jupiter ACE

      Jupiter ACE? I recall a Franklin ACE. I could be confusing old machines -its a long time ago. My CP/M modem program got transmogrified into "ACE Talk" or somesuch.

      1. Nick Pettefar

        Re: Jupiter ACE

        The Jupiter Ace was the one that caught fire.

    5. Blue Pumpkin

      Re: Jupiter ACE

      A fully fledged FORTH implementation does everything including its own disk I/O.

      I wrote a FORTH interpreter/compiler whatever you call it for the 8086 in assembler and it came in at under 8KB - which at the time was a big plus when memory was more expensive than programmers.

      FORTH - quirky definitely, elegant yes in lots of places, but maintainable, usable .... not so sure :)

      1. Anonymous Coward
        Anonymous Coward

        Re: Jupiter ACE

        The boot prom code for Sun's SPARC systems, essentially the BIOS, was written in FORTH.

        1. Anthropornis

          Re: Jupiter ACE

          Yes - Open Firmware. In the days of PPC macs they used that, searching on google suggests more-modern intel macs either used, or used to use, that.

          1. MarkMLl

            Re: Jupiter ACE

            Related code was used in boot ROMS from IBM and Apple at various times. It went on to be used on the One Laptop Per Child machines and never lived it down.

      2. General Purpose

        Re: Jupiter ACE

        Forth was, quite magnificently, a Write-Only language.

      3. flashydave

        Re: Jupiter ACE

        I wrote most of Kuma Computers FORTH implementations for things like Sharp MZ80K MZ80B, Newbrain, Tatung Einstein, Osborne 1, Tulip computer, Atari ST, Commodore Amiga and several other Forths for 68k series boards and some military machines as well as for IBM PC.

        All were written in Forth (using inbuilt compiler and assembler or even cross-assembler when moving to a new platform).

        Biggest mission critical application was my Walton Hindsight RARE/ARR radar recorder in use at CAA for many years in the 1990s and 2000s used to record air traffic movement and Comms. Ran on multiple 68k machines and can be seen working at the National Computer Museum at Bletchley Park.

  7. Arthur the cat Silver badge


    Not joking, the early versions of PR1MOS, the OS for Prime machines, were written in Fortran 4 (with a few system-ish hacks like a predefined common block that was all of memory, and assignments missing left or right sides to set or get the accumulator). Later versions were in PL/P, a systems programming dialect of PL/I.

    1. bazza Silver badge

      Re: Fortran

      My first ever proper job - aged 18 - was on Prime's coding in PL/P. Happy memories.

    2. Warm Braw

      Re: Fortran

      There's a reference on Wikipedia to an operating system written in COBOL. While I can find other sources for the existence of the product and its focus on running COBOL applications, I'd be interested to see some confirmation of the extent that COBOL featured in the OS, particularly given the variety of peripheral hardware it apparently supported: I don't fancy writing a device driver in COBOL...

      1. Anonymous Coward
        Anonymous Coward

        Re: Fortran

        Well, I don't fancy writing anything in COBOL.

        1. Anonymous Coward
          Anonymous Coward

          Re: Fortran

          COBOL is fairly easy. It's RPGII that's a bitch.

    3. Anonymous Coward
      Anonymous Coward

      Re: PR1ME

      ah ..

      SMSG$, which was a wrapper to MSG$

      there was also the proto TCP stack (using X25 ?) that daemons used.

    4. Ken Shabby

      Re: Fortran

      PRIMOS also had SP/L, another PL/1 variant. Lots of PMA, Prime Macro Assembler., They were moving to Modula 2

      As for C well Primes did not have byte addressing, Prime ASCII had the top bit set and null pointers were not 0.

      1. MarkB

        Re: Fortran

        "As for C well Primes did not have byte addressing, Prime ASCII had the top bit set and null pointers were not 0."

        Byte addressing was possible. The original architecture had 32-bit pointers which addressed down to the 16-bit "half-word", and 48-bit pointers where the additional 16-bits contained a 0 or a 1, to reference a byte within a half-word (!)

        As best I remember (it's a while ago) there was a new addressing scheme introduced - specifically for the later versions of the C compiler - which allowed for byte addressing in 32-bits. I forget the fine details, but they can probably be found on one of the sites run by ex-pr1me-mates.

        The null pointer thing is perfectly legitimate in C, but made porting C programs which tried to treat pointers as integers a little difficult.

        Other challenges included segmented memory where addresses wrapped at segment end rather than rolling into the next segment, and lack of native byte-based I/O (again, the natural unit for any manipulation in Primos tended to be the 16-bit half-word).

        Porting C to Primos was generally hard and often unsatisfactory as I recall - it was a good test of whether your C was actually clean...

        PL/P and SPL I remember as being quite nice - PL/P was a little challenging as it was intended for kernel use, so had some interesting limitations (and a quirky compiler based on old technology), while SPL (more for user-space code) was almost identical to PL/1-G (and I believe used the same compiler technology) but using library calls rather than language syntax for I/O.

        I never saw any of the FORTRAN code, which is probably a good thing. Later on, some system code was written in MODULA-2. I don't believe C was ever used significantly internally - it was provided for porting software (for example to make Oracle available on Prime) and for customer use.

    5. Stuart Dole

      Re: Fortran

      When I was working at a large teaching hospital, I managed a lab with a DEC ecosystem (started with RT-11, then some sort of multi-user version of RT, then RSX-11m), and did most of my coding in FORTRAN (and assembler). A friend ran a similar (larger) lab that ran UNIX on a VAX. His productivity was about 3x mine, writing mostly in C.

      Then I found out about RATFOR, a C-like syntax, with a pre-compiler, for FORTRAN. I got a version at one of the many DECUS meetings (ah - the days before software patents!!) when we all shared code, and it greatly sped up my productivity - and code readability!

  8. bazza Silver badge


    One of the many varieties of OS / language from the 60s, 70s, had to win, it just happened it was C and UNIX.

    What really cemented it though was the US DoD, in the 1980s, effectively plumping for the UNIX and C with POSIX. That cast an official US governmental seal of approval on C and *nix style operating systems, and that was that. At the time it was rapidly becoming the de facto choice anyway, but after that there was no money to be made in developing something radically new and trying to sell it to what was at the time one of the biggest customers in the market.

    1. Mage Silver badge

      Re: really cemented it though was the US DoD, in the 1980s

      Actually USA DoD plumped for ADA in 1980s. C was a decade earlier.

      GNU, BSD etc and later Linux born because the developers of UNIX thought AT&T unfairly had copyright. A lot of it wasn't paid for or developed by AT&T.

      POSIX is a separate thing from UNIX.

      1. bazza Silver badge

        Re: really cemented it though was the US DoD, in the 1980s

        DoD didn't mandate Ada until 1991, but granted a ton of exceptions. Not many projects actually went ahead with Ada, being based on C / Posix instead. The "Ada" mandate lasted 6 years only.

        In 1988 POSIX effectively defined the standard against which one had to write C code to be portable as per DoD's requirements (which is what the DoD actually wanted). By 1992 POSIX was also specifying command shell and command line utilities. POSIX and The Single Unix Specification merged in 2001. At the end of the 1980s DoD also mandated open hardware standards for various classes of system, plumping for VME (which is still supported to this day). ADA, where it was used, had to fit in on top of all this.

        It depends on what you mean by "Unix". These days, something can officially be labelled "UNIX V7 (tm)" if it passes the Open Group's compatibility tests against POSIX:2008 2013 edition, aka Single Unix Specification v4. Note that OSes can meet these requirements even if their native shells, APIs, etc. are not unix-like in anyway whatsoever.

        Pretty sure Linus did Linux for fun / university, originally, not because he was passionate about the corporate doings of AT&T. FreeBSD was the open re-write project that was motivated to wrest "Unix" out of proprietary control. It came out at about the same time as Linux. Both ended up achieving the same end result.

      2. Roland6 Silver badge

        Re: really cemented it though was the US DoD, in the 1980s

        >Actually USA DoD plumped for ADA in 1980s.

        And Intel failed to deliver a chipset (iAPX 432) that directly supported Ada...

    2. Anonymous Coward
      Anonymous Coward

      Re: Declarative

      That's just not true.

      Unix and C won in the 1980s because (a) they were far superior to the alternatives; (b) vendors could port Unix and C to their hardware far more quickly and cheaply than developing and maintaining their own OS and compilers; (c) the market was moving to desktop workstations and these mostly ran some variant of Unix; (d) customers and developers really liked the concept of open systems (=> no vendor lockin through custom APIs and supposed ease of migration between vendor platforms); (e) Unix IPR was open to any vendor on equal terms because it was owned by AT&T which wasn't allowed to be in the computer business and therefore couldn't use Unix to eliminate competitors.

      The DoD did insist on POSIX compliance - sort of. But they didn't enforce this. Not that (lack of) POSIX compliance hindered sales to the DoD from Microsoft, DEC, IBM, DG, HP, Burroughs etc. They still bought shitloads of non-Unix mainframes, PCs and minis from those vendors.

      Back in the 80s, it was considered witchcraft that the same source code could compile and run on different hardware and software from the likes of DEC, Sun, HP, IBM and the rest. Today we take that for granted. Unix and C made that possible.

    3. Dan 55 Silver badge

      Re: Declarative

      The DoD mandated POSIX (C is part of that, UNIX isn't) This is why MS gave Windows NT a POSIX-compliant API.

  9. R Soul Silver badge
    IT Angle

    Necrophilia for fun and profit

    This article is the equivalent of the era of bubonic plague when a guy with a cart went around saying "bring out your dead, bring out your dead".

    1. karlkarl Silver badge

      Re: Necrophilia for fun and profit

      Heh, I do agree but...

      "bring out your dead, bring out your dead"

      I can't quite yet. We still need our dead to run the entire industry ;)

      Not to mention, dead stuff is always more stable. I.e you wouldn't exactly build a house out of *living* people would you?

      1. TRT Silver badge

        Re: Necrophilia for fun and profit

        I wouldn't build a house out of dead people either. It would get rather smelly and unhygienic.

        Mind you, I suppose that invites the philosophical viewpoint that when you die, your body doesn't... it's just becomes a somewhat different sort of "living" - more of an ecosystem.

        1. David 132 Silver badge

          Re: Necrophilia for fun and profit

          >I wouldn't build a house out of dead people either.

          I have a car - a Lotus, actually - made out of dead people.

          It's my Esprit de Corpse.

          (sorry, not sorry)

      2. Anonymous Coward
        Anonymous Coward

        Re: Necrophilia for fun and profit

        "I can't quite yet. We still need our dead to run the entire industry ;)"

        So you're saying you feel better, you think you'll go for a walk?

    2. Arthur the cat Silver badge

      Re: Necrophilia for fun and profit

      This article is the equivalent of the era of bubonic plague(*)

      In some cases it's more

      Your father's OS. An elegant system for a more … civilised age(**).

      Multics, Burroughs' MCP and Genera all had features that today's mainstream OSes lack or do badly.

      (*) First known bubonic plague outbreak was ~3000 BCE, it's still around today. Long era.

      (**) ObXKCD.

      1. heyrick Silver badge

        Re: Necrophilia for fun and profit

        "all had features that today's mainstream OSes lack or do badly."

        Once upon a time it was a fairly easy job to undelete a file, just as long as you had your "oh shit" moment right away.

        All these fancy dodahs these days, nuke a file and it's gone for good. Delete a folder by mistake and everything vanishes in a microsecond with no way of undoing it (and since you don't have low level access to anything without jailbreaking, you can't even try to retrieve whatever might remain).

        Yup, progress.

    3. Baroda

      Re: Necrophilia for fun and profit

      I wish I could find the Telegoons scene I think you are referencing where it opens with Grytpype-Thynne reading a book titled ‘Brain surgery for fun and profit’...

      1. Arthur the cat Silver badge

        Re: Necrophilia for fun and profit

        "For fun and profit" is an old trope(*), much used. Pr1me's manual for their text formatter used to have examples involving the "Raniburger Corp" handbook "Frog breeding for fun and profit".

        (*) And much debated, see Stack Exchange's thread on it.

  10. Arthur the cat Silver badge


    Xerox Parc machines could and did run Smalltalk-80 all the way down to the bare metal.

    For a brief moment HP (nearly) had a pure Smalltalk-80 box running on a NatSemi 32032. I had a prototype to play with under NDA and for the time it was a rather fine, if specialist, workstation. However, it developed a hardware fault so they took it back on a Friday and by Monday HP had always been at war with Eastasia had never had a Smalltalk machine and never even considered developing such a thing. If it hadn't been for the h/w fault I might have managed to keep a non-existent HP ST-80 box as a home computer.

    1. timrowledge

      Re: Smalltalk-80

      I had an early NS32032 machine ~1983, though I never got Smalltalk running on it (I wrote a very simple 3D interactive solid modeller on it, terrible performance).

      On the other hand I had Smalltalk running on ARM before more than a couple hundred people knew about ARM. And ~25 years ago I was working on a Smalltalk medium-hard real-time OS on custom ARM hardware. It worked quite well, and was intended for a consumer network/media system that would have given us al the useful parts of IOT in the mid 90s. If only bill gates hadn’t stuck his foot in it...

      Others have made Smalltalk sorta-OS systems too. So much nicer .

  11. Greybearded old scrote Silver badge

    Another Pascal system

    MacOS < 7.0 was Pascal. I don't think they ever replaced it all with C before OS X.

    1. F. Frederick Skitty Silver badge

      Re: Another Pascal system

      The core was actually all 68K assembly language.

    2. Liam Proven (Written by Reg staff) Silver badge

      Re: Another Pascal system

      *Parts* of it were in Pascal, which is why some APIs needed Pascal calling conventions. Not all of it, though, which is why I specifically didn't mention it.

      1. Anonymous Coward
        Anonymous Coward

        Re: Another Pascal system

        Indeed, and had the mainstream OSs of today been written in Pascal you'd have been writing how Pascal was an IDL.

        Which of course it is.

  12. Anonymous Coward
    Anonymous Coward

    Ghosts in the machine

    The scariest ever and now dead OS from the 80s was the thing that ran on Symbolics Lisp workstations. IIRC it was written in Lisp and let the end user change the CPU microcode (also written in Lisp?) on the fly whenever they felt like it.

    1. Tom 7

      Re: Ghosts in the machine

      I think the core Lisps were generally built around SECD machines which I guess you easily implement in machine code (CAR and CDR were taken from the machine code of the IBM704), Or equally simply create a hardware implementation of it. Symbolic Lisp Machines made machines with that in mind but never quite got round to doing it fully in silicon.

    2. Arthur the cat Silver badge

      Re: Ghosts in the machine

      The scariest ever and now dead OS from the 80s was the thing that ran on Symbolics Lisp workstations.

      Genera was wonderful, a really good OS that I loved(*) with a proper space cadet keyboard too. Shame about the hardware's need for cooling though, not so much fan noise as fan jet noise.

      (*) Happy fun times back then, I had a Sun workstation, a Symbolics and the non-existent Smalltalk machine(**) on my desk(s).

      (**) See other comment for details.

      1. Anonymous Coward
        Anonymous Coward

        Re: Ghosts in the machine

        (Although(Lithp(may be(a good(solution)for)some things))I)am(not(really(sure(I)ever))))discovered)what)they)were)))

        1. Chris Gray 1

          Re: Ghosts in the machine

          I always figured that the AI crowd of the time wanted a language in which new code could be easily created at runtime because *their* fancy AI project was going to be smart enough to do it usefully.

        2. Anonymous Coward
          Anonymous Coward

          Re: Ghosts in the machine

          It was (is) a good way to overuse parenthesis.

          1. Warm Braw

            Re: Ghosts in the machine

            Maurice Wilkes used to introduce his LISP lectures saying it stood for "Lots of Irritating Superfluous Parentheses".

        3. Arthur the cat Silver badge

          Re: Ghosts in the machine

          All (untyped) languages aspire to the condition of Lisp.

          Historically I'd say that Lisp was the test bed in which we as a profession worked out exactly what the hell it was we were actually doing when we designed and used computer languages. If you look at all the debates which came up in the Lisp community - scope, dynamic vs static binding, downwards funargs, upwards funargs, closures, single vs dual namespaces, continuations, macro hygiene, message sending, purely functional vs stateful programming - they reflected design and implementation choices that occur in all languages, but which could be tested rapidly in Lisp because it is such a simple and flexible language. As such it's in many ways the Ur-language from which all other languages have sprung even if it's always been a minority sport in real world use.

          1. Anonymous Coward

            Re: Ghosts in the machine

            Lisps are typed but not usually statically typed. Some Lisps are statically typed.

          2. BobbyTables

            Re: Ghosts in the machine

            Lisp is the only truly beautiful programming language I've found. It's pure elegance. In the last year since starting to use it, I've learnt so much about being a better programmer from it that I missed in years of C-like languages, and I'm not even using it in an especially idiomatic way.

            What really shocked me about it was finding out it originates from the 1950s. It's the polar opposite of Fortran, the only other language of the time. You're right that it was used as a test bed for just about everything modern languages have, and it had an alarming amount of it from early on. It's hard to think that garbage collection was being added to Lisp only a year or two after the modern "if" was invented (in Lisp, naturally). It brought so much innovation to the table all at once. Like the Citroen DS of programming languages.

            I'm surprised AI has moved away from it. Its effortless self-modification capabilities would lend itself well to modelling ML concepts would it not? Not my field, not my problem.

            I'm fortunate I'm able to use it at work, and it's been a real blessing. It's a shame I probably won't be able to use it more directly in my later career.

        4. Anonymous Coward

          Re: Ghosts in the machine

          Thing that Lisp is good for is writing programming languages. All large projects end up implementing at least one programming language but usually do not know they are and so it is terrible thing made up of m4 and worms. Lisp programs know they are.

  13. Paul Crawford Silver badge

    You can create OS and applications in any language really.

    But some lack the dirty aspects of memory management (and even lower like CPU protection switching) so they need bits in assembler or something C-like. Equally such low-level code has enormous potential to screw the system.

    Horses for courses really, and most decisions come down to what will do this job well enough to get by.

  14. GreggSchoenberger

    Fortran-based Operating Systems

    Lawrence Livermore needed an operating system with more features than what was offered by the vendors of supercomputers at the time - classified level support, time-sharing, etc. So they rolled their own. LTSS for the CDC and Cray machines, CTSS for Cray hardware, and later a new version of LTSS - NLTSS for Crays. All of these systems, utilities, support libraries were written in the local dialect of Fortran-77, later Fortran-90.

    All of the systems used concepts developed for Multics, but were heavily modified to suit the needs of the laboratory computing community. One notable feature was the mapping of program memory to disk ( aka core dump ) was also used for swapping out when the time slice expired AND was restartable.

    Eventually these systems were replaced by Unix derivatives - notably Linux.

    1. Mike 16

      Re: Fortran-based Operating Systems

      Please tell me more. A friend worked at Lawrence Livermore and once mentioned an OS, written in Fortran, for a ModComp computer. Would that have been related?

      I do know that he worked in the not-networked systems, which were used for unclassified and highly classified jobs. Not at the same time, of course. Context switches involved physical removal of all storage media, and armed guards.

  15. Norman Nescio Silver badge


    I suppose TempleOS belongs in the C-like category. Written in HolyC.

  16. Anonymous Coward

    In terms of popularity [ ... ] Rust is eclipsing C++

    Yeah, right. My ass.

    Here's the thing: people who write C or C++ software don't feel the need to spam the world with announcements, pronouncements and self-promoting spam. They just do shit, quietly. It happens to be shit of consequence.

    But, there's a small community of Rust fanbois who are just very loud. And that's because that part of the world where consequential stuff happens doesn't pay much attention to them.

    So, Rust wants to stick its tail into the Linux kernel. Wants to hang out with the bro's. Respect Mah Authoritaaaaay!!! [0]

    How did that go? Whoops! Thar she blows. Something about operating systems, ABI's and calling conventions.

    Rust's reaction? Fuck C!!

    And it's not even because Rust has something concrete to offer to the Linux kernel. The prevailing advantage of Rust over C that's being pushed around by fanbois is: it's safer to write in Rust than in C. Translation: Rust makes an inept C pointer boob less of an inept boob. And that's somehow reassuring?

    It's just an ego trip. Rust wants to be in the Linux kernel because it thinks the Linux kernel is cool, so that's where Rust wants to hang out. With the cool kids.

    Know thy limits, Rust. You're just a pile of marketing talk being pushed by Microsoft and Google, in their quest for the complete monkeyfication of the software engineering profession.


    [0]: Cartman. See: South Park

    1. Lunatic Looking For Asylum

      Re: In terms of popularity [ ... ] Rust is eclipsing C++

      Have a beer sir. Sorry about the icon but it was the nearest I could get to oxidisation.

      When I was reading the article I just knew there'd be a 'rust angle' in it somewhere. It wasn't _really_ about C was it.

      I think we're going to need another icon before too long, rust gets way too much air time here, it's in danger of becoming the new systemd.

      1. ClockworkOwl

        Re: In terms of popularity [ ... ] Rust is eclipsing C++

        There are many ways to 'kill' rust, my favourite involves aluminium powder..!

      2. Chris Gray 1

        Re: In terms of popularity [ ... ] Rust is eclipsing C++

        I've been (slowly) reading the Rust doc. I just want an understanding of what it does at the lower levels - haven't got far enough yet. What *is* "borrowing"? The language appears to not have any kind of struct with named elements - perhaps thats added with their macro stuff. They seem to think that declaring a local variable of a given type a few lines after a previous declaration with a different type, thus shadowing the old one, is a *good* thing. WTF???

        1. ssokolow

          Re: In terms of popularity [ ... ] Rust is eclipsing C++

          > What *is* "borrowing"?

          Semantically, it's locking a compile-time reader-writer lock that gets completely eliminated during the compilation process. (`&` is shared reader, `&mut` is exclusive writer)

          Implementation-wise, it's taking a pointer to something.

          > The language appears to not have any kind of struct with named elements - perhaps thats added with their macro stuff.

          Could you clarify what you mean by "struct with named elements"?

          Here's some runnable example code for the cases I imagined you might be referring to.

          > They seem to think that declaring a local variable of a given type a few lines after a previous declaration with a different type, thus shadowing the old one, is a *good* thing. WTF???

          It's a trade-off they considered acceptable, given how strict the type system is, in order to enable things like:

          let req = HttpRequest::new();

          let req = req.begin_streaming(); // `req` no longer has methods to set headers

          (The "typestate pattern", where changes in type are used to implement a compile-time verified state machine and the borrow checker is used to prevent you from holding and using references to stale states.)

    2. DrXym

      Re: In terms of popularity [ ... ] Rust is eclipsing C++

      That has to be the silliest straw man I've read for some time.

      Rust can call C and C can call Rust. It's not even hard to do. There are even explicit language constructs for it so that function names aren't mangled and structs are packed the same way. It can even be used in kernels and against bare metal. That is not "fuck C" by any stretch, since if you have C code that works you can just call it. If you have new code in Rust you can call it from C. I call OpenSSL all the time from my Rust code. No biggie.

      So if you love C so much, then that's fine please continue using it. Nobody is forcing you to write in Rust even if the reasons others may do is obvious and self evident - i.e. less bugs in compiled code, more scalable thread safe code.

      Just keep writing C. Or you could go on a ridiculous ill-informed tirade every time Rust is mentioned. Somehow I expect it'll be the latter.

    3. mr-slappy


      Thank you for numbering your footnotes from 0. Respect.

    4. Anonymous Coward

      Re: In terms of popularity [ ... ] Rust is eclipsing C++

      Translation: Rust makes an inept C pointer boob less of an inept boob.

      Translation: Rust significantly reduces likelihood of class of errors which have given rise to and continue to give rise to almost all security vulnerabilities in software systems.

      Apparently this is bad thing.

      1. Someone Else Silver badge

        Re: In terms of popularity [ ... ] Rust is eclipsing C++

        Apparently this is bad thing.

        It's not a bad thing -- for copy-pasta types who fashion themselves as "programmers" ... no, that is too generous ... "coders" who will never ascend, nor even aspire to ascend, to any sort of level of expertise or excellence in the field.

        c.f. web programmers (not that your bog-standard web programmer could be arsed to learn Rust).

  17. innominatus

    BCPL over C

    Ouch "C fans tend to regard BCPL as an unimportant transitional step"! BCPL has more expressive flow control than C, it's compiler is designed for easy portability to new architectures, and it's closer to the machine for systems programming. Back in the day I've worked on compiler and run-time library ports across multiple target platforms that allowed a single application code base to work seemlessly across them all. Ah, nostalgia ain't what it used to be...

    1. Dan 55 Silver badge

      Re: BCPL over C

      Here's an interview with one of the developers of TRIPOS, written in BCPL, which he ported to the Amiga (i.e. AmigaDOS). It also goes over what he did afterwards.

      Interview with the creator of AmigaDOS

    2. Tim Parker

      Re: BCPL over C

      "C fans tend to regard BCPL as an unimportant transitional step"!

      I wouldn't take that as too much of a real criticism of BCPL, I think it may be more projection than anything else.

    3. DrXym

      Re: BCPL over C

      I've never programmed in BCPL but code samples look like it would be easy to parse & tokenize into an AST and spit out machine code. Far more so than C. That's probably why it enjoyed some early success, especially when C was kind of an ad hoc mess until ANSI C put some semblance of portability onto it.

      Once that happened the reason for BCPL kind of died with it. I know AmigaOS 2.0 began the migration to C and I wonder what compiler they used. I remember using Lattice/SAS C on the Amiga which was pretty good but there was also an Aztec C which wasn't so great.

    4. Tim Parker

      Re: BCPL over C

      I think that's a bit of projection (again) on the author's part. Someone seems to have a bit of a cob on about C at the moment for some reason.

    5. Anonymous Coward
      Anonymous Coward

      Re: BCPL over C

      it's closer to the machine for systems programming

      ... if that machine is word-addressed. C assumes the world is a giant PDP-11: BCPL assumes the world is machines which were obsoleted by the PDP-11.

  18. ColinPa

    Not all operating systems were written in C

    IBM's mainframes (VS1, MVS, VSE, the original DOS, zVM) running on 360/370/390 hardware were not written in C. 40 years ago they were written in Assembler, and PL/S (A pl/1 syntax like language). This evolved into PLX which is used these days.

    These days application type stuff like web servers (and TCP/IP) may be written in C and Java. Even if you wrote in "Metal C" which was closer to the hardware, you still have to drop into assembler to do the hard stuff.

    C has a rich library of functions like printf(), but the assembler and PLX had equivalents but they were not so easy to use.

    1. QuiteEvilGraham

      Re: Not all operating systems were written in C

      Hi Colin,

      You commented whilst I was adding mine.

      Metal C basically spits out assembler, which gets assembled. We've thought about it, due to the increasing number of instructions that appear with every iteration of IBM hardware which the Metal C guys (and gals) save you the bother of thinking about.

      I write a whole load of C for mainframe these days, but remain convinced that the string functions are the work of the devil in terms of good practice. Also, I imagine that any reputable software house had some analogue of most of the functions in the C runtime 30 years ago. I'm still using a printf/sprintf()-like thing that I knocked up 20 years ago on OS/390 run under the Hercules emulator.

      The big problem in the interesting end of the mainframe world is that the people doing it are all getting old, and not getting replaced.

  19. QuiteEvilGraham

    Another OS, not C or Rust, or anything like that.

    Just the other week, I wrote a routine in assembler, to add a little function as a product enhancement to things running on an OS mainly written in assembler.

    I didn't see it mentioned in either the article or the comments when I posted, and it might not be the most common in terms of the number of machines that run it but it is a common thing when you consider how many financial transactions run through it.

    Ladies and Gentlemen, I give you - z/OS.

    1. Liam Proven (Written by Reg staff) Silver badge

      Re: Another OS, not C or Rust, or anything like that.

      I did explicitly say that I was intentionally excluding things written in assembly language...

      1. eldakka

        Re: Another OS, not C or Rust, or anything like that.

        Ahh, but you said it in English. There's the problem. It should have been written in assembly.

  20. fg_swe Bronze badge

    HP MPE

    MPE was a very successful business (as opposed to scientific and technical) computer operating system.

    MPE had a rough start, but after a couple of years it developed into a rock-solid OS, loved by loyal customers of the corporate world.

    It was in fact a kind of economic mini-mainframe which could connect thousands of end user terminals for transaction processing, email, order processing, manufacturing management and the like.

    It was implemented in a kind of Pascal.

    MPE would still be in use if customers had to make the call, because it was so reliable and secure.

    1. fg_swe Bronze badge

      Re: HP MPE

      1. Liam Proven (Written by Reg staff) Silver badge

        Re: HP MPE

        There's a passing mention of the HP 3000 series in there, under things Burroughs inspired, but I'm afraid I just know next to nothing about them.

        I'm not claiming that entire piece was written from memory -- I did a lot of fact-checking -- but most of it springs from my own research over the last few years.

        I'm very glad to see that people seem to be enjoying it.

  21. Thought About IT


    The MPE operating system of HP3000 minicomputers was written in SPL. This was a perfect match to the stack based architecture so it was easy to write compact, fast code commensurate with the limited RAM available in those days. Hewlett-Packard also made the HP1000 which on paper was faster hardware, but running theiir version of Unix (HPUX) and programmed in C, was a dog compared to the HP3000. My language of choice is now C++.

    1. Down not across

      Re: SPL

      I loved writing stuff in SPL for MPE V on my Series 39. The intrinsics were very well documented. Not quite the "DEC grey wall" but not bad documentation.

      I never did try MPE XL as all my HP9000 PROMs are configured for HPUX. There is a way to unlock the PROM so you can boot either one allegedly.

  22. ColonelDare

    Qdos anyone?

    Happy days wrestling with my first multitasking operating system. A quantum leap [pun intended] in possibilities for me having just progressed from a hand-coded assembler 'monitor' program running on a home-brew Z80 machine.

    I was super impressed but didn't get too far, however I believe a smarter guy than did:

    Linus Torvalds interviewed by Jeremy Allison

  23. Throatwarbler Mangrove Silver badge


    As I recall, the Be engineers had a rule: no C++ in the kernel. Everything else might have been C++, but the kernel was written in C IIRC.

  24. BinkyTheMagicPaperclip Silver badge

    Windows needs C++, and non C OS need a cool factor

    If you're going to go down the 'this is a C++ operating system route' based on some parts of the OS, Windows is also a C++ operating system.

    Sure, the Windows kernel API is C based, but if you want to write interface components or drive various data querying and transport objects you'll fire up a C++ compiler if you have any sense. That's how the interfaces are specified.

    The difficulty I have with Rust and others is the fundamental question 'is it doing anything cool?'. The answer to the end user is generally : no. Yes, security professionals and some programmers love it for excellent reasons, but a quick look at the available Rust OS offerings shows they seem to be stuck very firmly in architecture research rather than day to day usability.

    BeOS was a terrible OS[1], but at least it tried to do some cool things at the time, and definitely managed to do so with the BeBox.

    It shouldn't be news that security, backup, and networking that doesn't fall over tend not to be selling points. What's on offer has to be a tangible improvement, and in general the record of C based OS on security and memory protection has improved significantly from the past.

    [1] At the time it came out for x86 I was running OS/2, which had multitasking, better networking, printing that actually worked, multimedia codecs that were somewhat better than those in BeOS, hardware support that wasn't completely desperate, and even OpenGL.

    1. Throatwarbler Mangrove Silver badge
      Thumb Down

      Re: Windows needs C++, and non C OS need a cool factor

      "BeOS was a terrible OS"

      BeOS was an immature OS. Within the parameters of its maturity, it was awesome.

    2. DrXym

      Re: Windows needs C++, and non C OS need a cool factor

      The Win32 APIs are C, not C++. I've written plenty of software where it's basically processing WM_ messages from a loop.

      The likes of MFC, ATL, QT, wxWidgets etc. are C++ but they're still using Win32 underneath it all.

      These days Microsoft have semi-deprecated Win32 for UWP. And while you can still write C++ with UWP it has a mess of extensions to the language to do so. So IMO it's not really C++ per se.

      As for Rust, there is huge interest in it from bare metal development all the way up to servers. I'm only aware of one kernel in Rust, reactos, but the progress made on it demonstrates it more than capable in that role. It's also used for webassembly development, webservers, databases, crypto, embedded devices, IoT etc. etc. Probably its weakest area at the moment is actually in UI development. There are plenty of frameworks (eGUI is very cool), but nothing that comes close to something like QT.

      1. DrXym

        Re: Windows needs C++, and non C OS need a cool factor

        I just realised I said Reactos when it's Redox OS. Oops

  25. Richard Tobin


    I don't know of any operating system whose kernel was written in Basic, but the system utilities of RSTS were.

  26. cantankerous swineherd

    an interesting compilation of obsolete and hobbyist operating systems.

  27. Kev99 Silver badge

    Here are two questions to which I've never received a clear and concise answer and it relates to this article.

    First, how is a new CPU or other processor first programmed? Going back in time, how did Intel get the 4004 or 8008 work if nothing like them had ever existed before?

    Second, how is a language made to function if it's the first of its type? How did Xerox or Bell bet their respective languages to work if they were built from scratch?

    To me it's all a variation of the "chicken or the egg" question. How do you know if a chip will function if there's no language for it? How do you know the language will work if there's no chip for it?

    1. Binraider Silver badge

      Assembler. And before that, nightmare territory of having to program directly at the per-bit level, by "literally" throwing the switches.

      The earliest concepts of what one might think of as an assembler appeared around 1947 on the EDSAC.

      All the power we have on tap today of course means an assemblers role is somewhat diminished by brute force capability. But there's a lot to be said for being able to operate right down at the hardware level. How many attack vectors are symptoms of design decisions in higher abstraction layers? Too many.

      Fully accept practicality of writing a full blown OS on todays myriad and modular hardware is a tough ask. Some people have tried to do it.

      1. Dagg Silver badge

        Assembler. And before that, nightmare territory of having to program directly at the per-bit level, by "literally" throwing the switches.

        I loved those switches. Hand translating your code, loading it into the console via the switches and run.

        Later once you had a tape you would manually enter the boot loader and run. Happy, Happy Joy, Joy. Real hacking.

      2. Arthur the cat Silver badge

        And before that, nightmare territory of having to program directly at the per-bit level, by "literally" throwing the switches.

        There was a stage before switches. I never did it but an older friend had the experience of "programming" hardware by plugging brass and ferrite slugs into a pinboard that then got inserted into an array of induction coils. Brass (non-magnetic) was 0, ferrite (magnetic) was 1.

        1. Tom 7

          Actually that was after switches - the first real modern computer- the manchester baby - had storage screen memory and the code was entered by switches. Core memory (called that because it was made using ferrite cores) came along later.

          1. Arthur the cat Silver badge

            This wasn't core memory in the RAM sense. This was magnetically based PROM holding the stored program. It couldn't be changed after the pin board was inserted. It wasn't a general purpose computer either - it was some sort of military device as my friend was RAF.

    2. coconuthead

      "How is a new CPU or other processor first programmed?"

      Usually an *emulator* is written for the target machine, which runs on an existing machine. Instructions are just 1s and 0s, so all you need is the definition of what they are (the *architecture*) and you can write a program to do the same thing on any computer.

      For example, when DEC developed the VAX they wrote an emulator for it that ran on their much larger PDP-10 mainframe. VMS booted on the emulator before any physical VAX existed. This allowed operating system and hardware development to proceed in parallel.

      "How is a language made to function if it's the first of its type?"

      You can find this discussed in a compiler textbook under the name "bootstrapping". There are several different strategies, depending on what you have available and whether you are designing a new language, a new CPU, or both.

      If it's just a new language L, you can write the first compiler for it in some other language Q. Then you write *another* compiler for L, this time in L itself, and use the compiler you wrote in Q to compile that. At this point your language is what is called "self-hosting" and you can throw the old implementation in Q away.

      On the other hand, if your language is already implemented on architecture W and you want to get it running on architecture X, you first modify the compiler you have on W to still run on W but output a program that runs on X. You then tell it to compile itself to X (still running on W), and copy the executable file from W to X.

      1. Marco van de Voort

        The Pascal language/compiler of the UCSD OS in the article is IIRC actually based on a bootstrap stage of the more complete mainframe Pascal compiler. The subset (P4) is bytecode to make the interpreter minimal and the compiler is sufficiently simple to run on it.

      2. Chris Gray 1


        Having done most of those steps, I'll just say "right on". (Designing programming languages and writing compilers is my hobby.)

    3. Tom 7

      The first machine were coded in binary - there was a website you could run a Baby (the first modern electronic computer!) but the code its was written in no longer runs on a browser but basically the binary code was set on switches and loaded into the memory, then the next bit of binary code was loaded and stored and once the program was loaded you set the start address and hit the run button. I would say its worth while for any programmer to try and get a grip on how a simple CPU works (or worked). Basically its a quite simple arrangement of switches and registers and a bit of logic. Laziness being the mother of invention the next thing that came along was assembly language where mnemonics replaced the binary codes and then they were changed into binary and entered. Then someone came up with the idea of an assembler that took a text file and converted that into binary and ran it. Once we got to that point (and allowing defines and macros and including other files etc ) we were pretty much where we are today - computer languages are really just smarter machine independent assemblers with attitude. can show you how the code works in silicon! But there are other 8080 virtual machines that you can easily run to see how assembler works!!

    4. Drishmung


      For example, the Burroughs Large System (B6700 etc, which has evolved to Clearpath), was always written in Algol. There was never an assembler for it. A compiler which emitted B6700 code was implemented on a B5000 (different architecture, different instructions), and the output of that compiler was used to boot the B6700. And of course, the compiler was written in Algol, so once the B6700 was running, subsequent compilation could be done on the new system.

      Looking at the source code for the MCP, and the patch history of it, there were in fact some lines which dated from the very first iteration.

      1. NorthIowan

        Re: Burroughs Large Systems There was never an assembler for it.

        Learned a bit about the Burroughs systems after the merger with Sperry. Apparently some people had a hard time believing there wasn't an assembler.

        It can take a bit of time to wrap your head around that. But hey, the compiler writers just need to know what binary to put out. Not much different then spitting out assembler code.

  28. Anonymous Coward
    Anonymous Coward

    Temple OS?

  29. Frumious Bandersnatch

    great memory lane

    ... but you had me at Wirthers.

    1. Arthur the cat Silver badge

      Re: great memory lane

      ... but you had me at Wirthers.


  30. Anonymous Coward
    Anonymous Coward

    Indeed C is everywhere just deep down

    As far I know every "modern" languages and frameworks end being written in C. Almost all I do not know even a single one modern language that is not implemented using C. Most compliers still are being implented using C to avoid higher language been blotaware and speed up just is time execution. When object programing was coming up and replacing procedural languages like C and Pascal was to solve shot coming of procedural languages like automatic memory management and implement object programing paradigms but they were not directly written in assambly they just used C libraries under the hood for compiling and generatiing executables and a reusable memory management native C code also was used to provide those capabilities to hover languages like Java. Even the celebrated C++ uses heavily C in its implementation in the early days. Most probably Go runtime is also written in C with reusbale memory management and process thread synchronization libraries. In fact C is much alive and present everywhere is just the generation of programers used to high level languages like Java Python , etc do not see the connection.

    1. Chris Gray 1

      Re: Indeed C is everywhere just deep down

      That's likely true, but is not required. Any language (which may have been bootstrapped via C) that allows the needed lower-level operations can be used to bootstrap from. So, it ought to be possible to bootstrap your way from Modula-2, for example. Hmm. There wasn't a decent C for the IBM mainframes, so my sequence there was AlgolW => QD => QC => ALAI. Don't bother trying to look up any but the first - you won't find anything.

    2. Marco van de Voort

      Re: Indeed C is everywhere just deep down

      Free Pascal is written in itself.

    3. ssokolow

      Re: Indeed C is everywhere just deep down

      The rustc frontend is written in Rust and was originally written in Ocaml. It currently uses LLVM as a backend, but they're working on an alternative backend for debug builds that's faster than LLVM but less optimizing. That's also written in Rust.

      Free BASIC appears to also be written in itself, as are Haskell and the PyPy implementation of Python. (PyPy's "translator" and JITing runtime use a subset called RPython which allows static types to be determined at compile time.)

      The term is self-hosting and it's considered a requirement for a language to be taken seriously in various circles.

      1. Marco van de Voort

        Re: Indeed C is everywhere just deep down

        Free Basic can generate assembler on x86 and generates C for gcc for the rest.

        Free Pascal writes ELF .o directly, but still uses LD on popular *nix targets.

        On more static targets like Windows and go32v2/dos it has complete stack (assembler/archiver linker, resource compiler and, finally, in the development version, a debugger).

    4. Anonymous Coward

      Re: Indeed C is everywhere just deep down

      Wow this is impressively wrong.

      Take SBCL (Common Lisp implementation, runs on *nix, Windows I think mostly x86/x64 now by look of it but compiler also targets many other architectures or has done so). Current git repo has 571,925 lines of Lisp code (including whole compiler of course, complete with 9 backends). 49,174 lines of C, all of it runtime support. 3,673 lines of assembler.

      Or Clozure Common Lisp: 417,298 lines of Lisp, 40,649 lines of C and related.

      For these languages and many others C is used as the necessary glue to stick the language to the platform, since the platform's native interfaces are all defined in C. And that is essentially all. Sometimes it is also used for low-level memory management (GC for instance).

    5. Bacon & Eggs

      Re: Indeed C is everywhere just deep down


      Would you think that mr. Putin is aware this process and long the journey really is from bootstrapping your to-be-designed programming language compiler upwards. It may take a while until you have completed hole sw stack from next to metal up to cloud of clouds as we currently are by solely using in-country developed stuff. No linux there unless you write your own compiler for C by using your own programming language compiled by your own proramming language bootstrapped to live somehow...

      Still, newly minted law prohibits to use foreign sw after 2025...

  31. Sanguma

    Anyone remember ...

    Per Brinch Hansen?

    My contention is that his Concurrent Pascal of c. 1977 was a microkernel in disguise, with a bundle of user-level operating system personalities though not much like what we'd call OSes these days.

    1. Arthur the cat Silver badge

      Re: Anyone remember ...

      Still got his Operating Systems Principles from 1973 on my bookshelf. (Next to the blue Smalltalk-80 book.)

      1. Tom 7

        Re: Anyone remember ...

        Operating Systems Design and Implementation, by Tanenbaum seems to available as a free PDF these days. Worth a read, The book you mentioned is free to download from the link you gave which is nice - there are later editions available too!

  32. Marco van de Voort


    Classic MacOS originally was in Pascal (up to V8 ?)

    Microsoft Windows 1.0 was said to be also in Pascal, though it was more a shell than an OS?

    IIRC the Modula2 OS was Lilith, and Modula2 was used a lot in embedded applications. Standalone application as a system language, but maybe doesn't count as OS?

  33. bikerbob

    Don't forget z/OS, It is written in a combination of Assembler, PL/S and PL/X (both derived from PL/I, with extensions to access the hardware) . And possibly others.

  34. Healeyman

    REALTIME, baby.

    Noob here, first comment, name's Bob (68yo retired programmer). My favorite OS, and best overall IMO, was one called RTE--for 'RealTime Executive--on HP1000 minis (descendant of the HP2100). HP got into the OS business because they needed a computer/system to manage all the test and measurement equipment they built (signal generators--including their first product; a synthesizer used to create sound for Disney's 'Fantasia'--spectrum analyzers, O-scopes, gas chromatographs ... you get the idea.). Also, to communicate with all their devices, on a single bus, HP invented the HP Interface Bus, or 'HPIB,' later to become IEEE488 parallel bus.

    The word 'realtime' gets bandied about, but there are actual criteria; basically, the machine's response has to be at all times deterministic. Obviously, responses cannot occur at the same instant as a stimulus, but in order to be considered 'realtime' the machine has to guarantee response within a specified maximum time. Since the 1000 was an I/O processor extraordinaire, this was accomplished as each I/O type--serial, parallel, etc.--had its own Z80-based processor, essentially a microcomputer with its own RAM, microcode, backplane hardware and specialized chips (e.g. UARTs). The CPU would specify an input's parameters, the I/O board would collect the input until the request was complete, DMA the data to main memory then fire an interrupt to tell the CPU ready to process the data when the DMA was complete. Depending on the process's priority, the CPU would save its state, service and process the interrupt then restore its previous state and process until a higher priority process needed servicing. By contrast, the later RISC-based HP3000 was strictly a polling architecture; the CPU would query each I/O subsystem in turn no matter its 'priority' (it was a round-robin process handler, higher 'priority' processes would merely get a larger time slice). The theory was the RISC processor was so speedy it didn't need true realtime capability but in testing the HP1000 'mini'--early versions used 4 x 4-bit microprocessors daisy-chained together for a 16-bit system--would routinely blow RISCy 3000s away. When I was at HP, 1983 to 1996, one of the 1000's applications was as the signal processing unit for AWACs early-warning aircraft. HP was obliged to continue supporting the 1000 into the 2000s for use in AWACs aircraft. I worked a contract programming a bank of HP instruments on IEEE488 run initially on HP Pascal, later on a micro using LabVIEW (ugh) for one of the GOES weather satellite's comm systems.

    I had fun in school with LISP--one of the Linux text editors is written in it IIRC--and Forth but the strangest language I encountered was an oddity from IBM called APL (for 'A Programming Language'). Commands parsed right-to-left and an assignment character was a left-facing arrow; there were specialized keyboards available for command symbols resembling Greek letters but us mortals had to use clunky ASCII transliterations. But, it had a single character command that would perform a full matrix inversion. Wonder what happened to it; was probably too far out of the norm for many to use.

    1. coconuthead

      Re: REALTIME, baby.

      APL was invented by Ken Iverson (actually as a notation before a programming language) and ran on more than IBM, although the most common implementation was on OS/360. I know it was still staggering along in 1980, being used for turnkey stuff in finance by a Canadian company called I.P. Sharp.

      The Lisp-based editor you're thinking of is emacs ("Eight Megabytes and Constantly Swapping", at a time when 4MB was a largish mainframe memory) and it has little to do with Linux. It arose from the MIT media labs and ran on pre-Unix operating systems like ITS. Then Richard Stallman reimplemented it with a Lisp interpreter written in C, from where it went everywhere. Up until a couple of years ago you could find it installed on every Mac.

      1. MarkMLl

        Re: REALTIME, baby.

        Yes, and the first computer implementation of APL was by Breed with Wirth as academic supervisor.

      2. larsbrinkhoff

        Re: REALTIME, baby.

        Not MIT Media Lab, but the AI lab.

      3. Deryk Barker

        Re: REALTIME, baby.

        Actually, EMACS (Editor MACroS) was originally a bunch of - surprise! - macros written in the TECO editor by various people and collected and made more uniform by Stallman at MIT.

        The next implementation was by Bernie Greenberg on Multics using MACLISP, which inspired Stallman to use LISP for GNU Emacs.

        You can read Bernie's account of all this here:

    2. Down not across

      Re: REALTIME, baby.

      HP1000 was awesome machine, although I had quite limited exposure to it. Was used a lot in process control etc due to its realtime capabilities, I mainly came across it in conjunction with data acquisition and instrumentation.

      I have a pre-RISC (labeled "classic" after the introduction of PA-RISC based machines) HP3000 running MPE V. Everything apart from serial I/O is based on HP-IB (7970E tape drive, 7911 winchesters (sans QIC option).

  35. Povl H. Pedersen

    Old stuff

    Macintosh OS 1.0 to 7.x was written in Pascal, and all interfaces were Pascal, no matter what programming language you used.

    OS X was a brand new OS.

    Early 1980-ties I wanted the white Forth computer, looked like a ZX-81½ but with rubber keys, like they later came to the ZX Spectrum.

    I doubt the ZX-81 with its 1kb of RAM had a C-based OS.

    I have been programming in assembler, BCPL, C, C++, Pascal, Modula-2 and many more. I think I was introduced to Oberon at university. But programming languages comes and goes. C has stuck around forever.

    1. A Non e-mouse Silver badge

      Re: Old stuff

      I doubt the ZX-81 with its 1kb of RAM had a C-based OS

      The Sinclair machines had lovingly hand-crafted Z80 assembler under the bonnet.

  36. DaemonProcess

    cryptus cunning lingua interruptus

    Go back far enough and the idea of purchasing an operating system for your computer was optional. The manuals described the hardware architecture, processor registers, i/o processing, data storage formats, switch functions etc. You could purchase an o/s or write your own in any language you could write a compiler program for.

    Fundamentally at a low level, the o/s language needs to able to cater for operations direct in CPU registers with specific hardware instructions, shared memory segments, the ability to read from / write to direct memory addresses, indivisible (test+set) instructions, interrupts,volatile latches or semaphores at known (fixed) addresses. Most languages these days try to abstract all this away from the possibility of harm. As CPUs these days are gaining more high level instructions (e.g. AES, TLS) then the number of languages to support it all reduces.

    1. adam 40 Silver badge

      Re: fell @ I/O

      Upvoted for the cunning stunt!

  37. adam 40 Silver badge

    SavajeOS - sorry it had a bit of C!

    Yes I wondered if that would get a mention, I was there a few years ago. God I get everywhere don't I?

    Anyhow even that wasn't pure Java (Java SE on a phone), there were sections of "native" code written in C, typically for a device driver etc, to get the performance up.

    But yes, to the user it appeared to be a Java O/S.

  38. djdel


    Surprised nobody has mentioned ICL's VME operating system for the 2900 and Series 39 mainframes. This was written from the ground up in S3, a high-level language designed by ICL based very closely on Algol 68.

  39. Blackjack Silver badge

    I really like Haiku but not gonna use it in more that a spare hard disk until it gets Final Beta status.

  40. Anonymous Coward
    Anonymous Coward

    Point not made...

    So, C isn't the be all and end all because of a load of systems that no-one uses anymore once existed?

    Actually VMS is an interesting example because I recall that being a bit of a pig to use in C.

  41. Roland6 Silver badge

    ARM Holdings Instruction Set Bias

    Anyone here taken a deep dive into the ARM architecture to determine it's instruction set is biased towards C or some other language and non-Unix like OS's?

    I ask as from the discussion so far this platform hasn't been mentioned, perhaps because it is designed for Unix/Linux and C.

    1. Binraider Silver badge

      Re: ARM Holdings Instruction Set Bias

      RISC OS was written specifically for the original ARM architecture; with a mix of Assembler, C, C++ and even elements in BBC BASIC! I imagine what we think of as the Kernel would all have been Assembler in those earlier versions.

      C based toolchains were developed from the get-go on ARM. Current RISC OS Open source (a cursory glance made in a few mins - not a proper dive) looks like it's largely C, C++ too. (Quite well annotated code too - if a few too many macros for my liking, though in something as big as a Kernel I understand the decision to use them).

      As has been noted elsewhere, C as a translation layer to Assembler on a PDP-11 was very direct. I don't think this is particularly the case with any other arch since then.

      1. Torben Mogensen

        Re: ARM Holdings Instruction Set Bias

        The first versions of RISC OS used no C whatsoever. IIRC, a C compiler only came later. ARTHUR, the predecessor to RISC OS, did indeed write parts of the GUI in BBC BASIC, but when RISC OS replaced it, the GUI was all assembly language.

        As for C influence on the ARM ISA, I doubt there was any. Yes, there are autoincrement/decrement loads and stores, but I believe these were inspired more by PDP11 and VAX, and were more general than the C ++/-- operators. Essentially, after you calculate an address (which can include a scaled register offset), you can write that back to the base address register.

    2. A Non e-mouse Silver badge
  42. Conundrum1885

    Is this picture poached from

    Stargate Atlantis by any chance?

    MGM aren't going to like that one bit, neither will Hermiod.

    (shocked Wraith face)

  43. StrangerHereMyself Silver badge


    I'm somewhat irked by the fact you guys forgot SerenityOS, a highly usable and advanced operating system written in C++. Its web browser recently passed the Acid3 web compatibility tests, which is quite a feat.

    Mind you that it Firefox is still building on code written more than 25 years ago whilst SerenityOS's web browser was written in just a few years.

  44. Some Random Kiwi

    PL-6 -- implementation language for Honeywell's CP-6

    Honeywell's CP-6 OS, the successor to Xerox' CP-V (itself following from BPM/BTM/UTS OSes, on Scientific Data Systems, then Xerox, Sigma series hardware) was implemented almost entirely in a new designed-for-purpuse high-level language, PL-6.

    As the CP-6 preliminary design review ( described it, PL-6 was:









    It lasted for at least a decade, but I doubt there are any systems extant.

    1. Deryk Barker

      Re: PL-6 -- implementation language for Honeywell's CP-6

      And bloody annoying it was to program in if you were used to PL/1.

      Way back when, Aberdeen University were looking to replace their system and wanted Multics, unfortunately Honeywell had cancelled Multics and sold them CP-6 instead (features included a flat file system - no directories, just a bunch of files per user - and the world's worst text editor - no buffers, changes were made *immediately* in the original file, which was really fun if you were editing code over a noisy phone line).

      So I ended up as part of the team implementing the "Rainbow books" (aka "Coloured books" used by JANET (the Joint Academic NETwork) in PL/6.

      Some of the Multics PL/1 code was ported -which was no easy task. Fortunately I got to write the connection manager (conman) from scratch.

      Not an experience I'd care to repeat.

  45. AlexeiDimitri

    And all died...

    And yet, the only real winner was C kkkkk

    1. Roland6 Silver badge

      Re: And all died...

      Still a distant second to the QWERTY keyboard.

      I suspect C's victory is a bit like VHS over Betamax; it wasn't the best but it was good enough and before you knew it, there wasn't really a choice: want to rent a video from Blockbuster, its going to be VHS.

  46. Stephendeg

    MirageOS on OCaml

    I’m surprised no one has mentioned MirageOS on OCaml

  47. UncleDavid

    And FORTRAN IV, of all things

    The first versions of the variously-named OS'es on Prime computers, apart from the necessary assembly portions, were written in FORTRAN, which seemed weird to me even at the time but became useful as we cycled through four different instruction sets. Primos added PLP (an in-house cut-down version of PL/1) for new stuff; I still have a listing of my PLP Apple LaserWriter driver. Then the language gurus came up with what they called SPL, which was an over-complicated version of PLP, but I think it was mainly a vanity project intended to exercise a new compiler-compiler technology. It sucked, but soon afterwards it disappeared along with the rest of the company.

  48. ipok

    MOSYS — another Modula-2 OS

    >> After his first sabbatical in Palo Alto in 1976-1977, once Wirth got back home

    >> to ETH Zürich in 1977, he and his team designed and built the Lilith workstation

    >> as a cheaper replacement for the $32,000 Alto. Its object-oriented OS, Medos-2,

    >> was entirely built in Modula-2.

    I was part of the development team at RSE lead by Brian Kirk that developed MOSYS for Motorola 68000 based workstations in the UK — we licensed the base Modula-2 compiler for Lilith from ETH. MOSYS was completely separate from Medos-2. It saw limited usage in the UK and was not a commercial success. The work was partially re-used for 68000 based embedded systems.

    I later moved to GEC Avionics where among other things I helped port the BCPC compiler to GEC4000 machines, which has an OS written in Coral-66 (also influenced by ALGOL) and Assembly Code. The Coral-66 compiler was written in BCPL which is why it needed porting to GEC4000 (from the VAX).

    1. cfbsoftware

      Re: MOSYS — another Modula-2 OS

      I was very interested to hear about your work on MOSYS. I initially read about it in the August 1984 issues of BYTE magazine (misspelt as MOSES!) and SAGE News. Do you know if any copies still exist? I would love to try it out on one of my SAGE II/IV systems.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like