Modernising RISC OS in 2020: is there hope for the ancient ARM OS?
The first computer I owned was a Sinclair ZX Spectrum, and I retain a lot of fondness for these tiny, cheap, severely-compromised machines. I just backed the ZX Spectrum Next kickstarter, for instance.
But after I left university and got a job, I bought myself my first "proper" computer: an Acorn Archimedes. The Archie remains one of the most beautiful computers [PDF] to use and to program I've ever known. This was the machine for which Acorn developed the original ARM chip. Acorn also had am ambitious project to develop a new, multitasking, better-than-Unix OS for it, written in Modula-2 and called ARX. It never shipped, and instead, some engineers from Acorn's in-house AcornSoft publishing house did an inspired job of updating the BBC Micro OS to run on the new ARM hardware. The result was called Arthur. Version 2 was renamed RISC OS [PDF].
(Incidentally, Dick Pountain's wonderful articles about the Archie are why I bought one and why I'm here today. Some years later, I was lucky enough to work with him on PC Pro magazine and we're still occasionally in touch. A great man and a wonderful writer.)
Seven or eight years ago on a biker mailing list, Ixion, I mentioned RISC OS as something interesting to do with a Raspberry Pi, and a chap replied "a friend of mine wrote that!" Some time later, that passing comment led to me facilitating one of my favourite talks I ever attended at the RISC OS User Group of London. The account is well worth a read for the historical context.
(Commodore had a similar problem: the fancy Commodore Amiga Operating System, CAOS, was never finished, and some engineers hastily assembled a replacement around the TRIPOS research OS. That's what became AmigaOS.)
Today, RISC OS runs on a variety of mostly small and inexpensive ARM single-board computers: the Raspberry Pi, the BeagleBoard, the (rather expensive) Titanium, the PineBook and others. New users are discovering this tiny, fast, elegant little OS and becoming enthusiastic about it.
And that's let to two different but cooperating initiatives that hope to modernise and update this venerable OS. One is backed by a new British company, RISC OS Developments, who have started with a new and improved distribution of the Raspberry Pi version called RISC OS Direct. I have it running on a Rasπ 3B+ and it's really rather nice.
The other is a German project called RISC OS Cloverleaf.
What I am hoping to do here is to try to give a reality check on some of the more ambitious goals for the original native ARM OS, which remains one of my personal favourites to this day.
Even back in 1987, RISC OS was not an ambitious project. At heart, it vaguely resembles Windows 3 on top of MS-DOS: underneath, there is a single-tasking, single-user, text-mode OS built to an early-1980s design, and layered on top of that, a graphical desktop which can cooperatively multitask graphical apps -- although it can also pre-emptively multitask old text-mode programs.
Cooperative multitasking is long gone from mainstream OSes now. What it means is that programs must voluntarily surrender control to the OS, which then runs the next app for a moment, then when that app gives up control of the computer, a third, a fourth and so on. It has one partial advantage: it's a fairly lightweight, simple system. It doesn't need much hardware assistance from the CPU to work well.
But the crucial weakness is in the word "cooperative": it depends on all the programs being good citizens and behaving themselves. If one app grabs control of the computer and doesn't let go, there's nothing the OS can do. Good for games and for media playback -- unless you want to do something else at the same time, in which case, tough luck -- but bad news if an app does something demanding, like rendering a complex model or applying a big filter or something. You can't switch away and get on with anything else; you just have to wait and hope the operation finishes and doesn't run out of memory, or fill up the hard disk, or anything. Because if that one app crashes, then the whole computer crashes, too, and you'll lose all your work in all your apps.
Classic MacOS worked a bit like this, too. There are good reasons why everyone moved over to Windows 95 (or Windows NT if they could afford a really high-end PC) -- because those OSes used the 32-bit Intel chips' hardware memory protection facilities to isolate programs from one another in memory. If one crashed, there was a chance you could close down the offending program and save your work in everything else.
Unlike under MacOS 7, 8 or 9, or under RISC OS. Which is why Acorn and Apple started to go into steep decline after 1995. For most people, reliability and robustness are worth an inferior user experience and a bit of sluggishness. Nobody missed Windows 3.
Apple tried to write something better, but failed, and ended up buying NeXT Computer in 1996 for its Unix-based NeXTstep OS. Microsoft already had an escape plan -- to replace its DOS-based Windows 9x and get everyone using a newer, NT-based OS.
Acorn didn't. It was working on another ill-fated all-singing, all-dancing replacement OS, Galileo, but like ARX, it was too ambitious and was never finished. I've speculated about what might have happened if Acorn did a deal with Be for BeOS on this blog before, but it would never have happened while Acorn was dreaming of Galileo.
So Acorn kept working on RISC OS alongside its next-gen RISC PC, codenamed Phoebe: a machine with PCI slots and the ability to take two CPUs -- not that RISC OS could use more than one. It added support for larger hard disks, it built-in video encoding and decoding and some other nice features, but it was an incremental improvement at best.
Meanwhile, RISC OS had found another, but equally doomed, niche: the ill-fated Network Computer initiative. NCs were an idea before their time: thin, lightweight, simple computers with no hard disk, but always-on internet access. Programs wouldn't -- couldn't -- get installed locally: they'd just load over the Internet. (Something like a ChromeBook with web apps, 20 years later, but with standalone programs.) The Java cross-platform language was ideal for this. For this, Acorn licenced RISC OS to Pace, a UK company that made satellite and cable-TV set-top boxes.
Acorn's NC was one of the most complete and functional, although other companies tried, including DEC, Sun and Corel. The Acorn NC ran NCOS, based on, but incompatible with, RISC OS. Sadly, the NC idea was ahead of its time -- this was before broadband internet was common, and it just wasn't viable on dial-up.
Acorn finally acknowledged reality and shut down its workstation division in 1998, cancelling the Phoebe computer after production of the cases had begun. Its ARM division went on to become huge, and the other bits were sold off and disappeared. The unfinished RISC OS 4 was sold off to a company called RISC OS Ltd. (ROL), who finished it and sold it as an upgrade for existing Acorn owners. Today, it's owned by 3QD, the company behind the commercial Virtual Acorn emulator.
A different company, Castle Technology, continued making and selling some old Acorn models, until 2002 when it surprised the RISC OS world with a completely new machine: the Iyonix. It had proved impossible to make new ARM RISC OS machines, because RISC OS ran in 26-bit mode, and modern ARM chips no longer supported this. Everyone had forgotten the Pace NC effort, but Castle licenced Pace's fork of RISC OS and used it to create a new, 32-bit version for a 600MHz Intel ARM chip. It couldn't directly run old 26-bit apps, but it was quite easy to rewrite them for the new, 32-bit OS.
The RISC OS market began to flourish again in a modest way, selling fast, modern RISC OS machines to old RISC OS enthusiasts. Some companies still used RISC OS as well, and rumour said that a large ongoing order for thousands of units from a secret buyer is what made this worthwhile for Castle.
ROL, meantime, was very unhappy. It thought it had exclusive rights to RISC OS, because everyone had forgotten that Pace had a license too. I attempted to interview its proprietor, Paul Middleton, but he was not interested in cooperating.
Meantime, RISC OS Ltd continued modernising and improving the 26-bit RISC-OS-4-based branch of the family, and selling upgrades to owners of old Acorn machines.
So by early in the 21st century, there were two separate forks of RISC OS:
Both are still the same OS, though, with the same cooperative multitasking model. RISC OS does not have the features that make 1990s 32-bit OSes (such as OS/2 2, Windows NT, Apple Mac OS X, or the multiple competing varieties of Unix) more robust and stable: hardware-assisted memory management and memory protection, pre-emptive multitasking, support for multiple CPUs in one machine, and so on.
There are lightweight, simpler OSes that have these features -- the network-centric successor to Unix, called Plan 9, and its processor-independent successor, Inferno; the open-source Unix-like microkernel OS, Minix 3; the commercial microkernel OS, QNX, which was nearly the basis for a next-generation Amiga and was the basis of the next-generation Blackberry smartphones; the open-source successor to BeOS, Haiku; Pascal creator Niklaus Wirth's final project, Oberon, and its multiprocessor-capable successor A2/Bluebottle -- which ironically is pretty much exactly what Acorn ARX set out to be.
In recent years, RISC OS has gained some more minor modern features. It can talk to USB devices. It speaks Internet protocol and can connect to the Web. (But there's no free Wifi stack, so you need to use a cable. It can't talk Bluetooth, either.) It can handle up to 2GB of memory -- four thousand times more than my first Archimedes.
Some particular versions or products have had other niceties. The proprietary Geminus allowed you to use multiple monitors at once. Aemulor allows 32-bit computers to run some 26-bit apps. The Viewfinder add-on adaptor allowed RISC PCs to use ATI AGP graphics cards from PCs, with graphics acceleration. The inexpensive PineBook laptop has Wifi support under RISC OS.
But these are small things. Overcoming the limitations of RISC OS would be a lot more difficult. For instance, Niall Douglas implemented a pre-emptive multitasking system for RISC OS. As the module that implements cooperative multitasking is called the WIMP, he called his Wimp2. It's still out there, but it has drawbacks -- the issues are discussed here.
And the big thing that RISC OS has is legacy. It has some 35 years of history, meaning many thousands of loyal users, and hundreds of applications, including productivity apps, scientific, educational and artistic tools, internet tools, games, and more.
Sibelius, generally regarded as the best tool in the world for scoring and editing sheet music, started out as a RISC OS app.
People have a lot of investment in RISC OS. If you have using a RISC OS app for three decades to manage your email, or build 3D models, or write or draw or paint or edit photos, or you've been developing your own software in BBC BASIC -- well, that means you're probably quite old by now, and you probably don't want to change.
There are enough such users to keep paying for RISC OS to keep a small market going, offering incremental improvements.
But while if someone can raise the money to pay the programmers, adding wifi, or Bluetooth, or multi-monitor graphical acceleration, or hardware-accelerated video encoding or decoding, would be relatively easy to do, it still leaves you with a 1980s OS design:
The result is something way smaller and faster than big lumbering modular PC operating systems which have to work with a huge variety of hardware from hundreds of different companies -- so the OS is not closely integrated with the hardware. But conversely, this design has advantages, too: because it is adaptable to new devices, as the hardware improves, the OS can improve.
So when you ran Windows 3 on a 386 PC with 4MB of RAM -- a big deal in 1990! -- it could use the hardware 16-bit virtualisation of the 386 processor to pretend to be 2, 3 or 4 separate DOS PCs at the same time -- so you could keep your DOS apps when you moved to Windows. They didn't look or feel like Windows apps, but you already knew how to use them and you could still access all your data and continue to work with it.
Then when you got a 486 in 1995 (or a Pentium with Windows NT if you were rich) it could pretend to be multiple 386 computers running separate copies of 16-bit Windows as well as still running those DOS apps. And it could dial into the Internet using new 32-bit apps, too. By the turn of the century, it could use broadband -- the apps didn't know any difference, as it was all virtualised. Everything just went faster.
Six or seven years after that, your PC could have multiple cores, but multiple 32-bit apps could be divided up and run across two or even four cores, each one at full speed, as if it had the computer to itself. Then a few years later, you could get a new 64-bit PC with 64-bit Windows, which could still pretend to be a 32-bit PC for 32-bit apps.
When these things started to appear in the 1990s, the smaller OSes that were more tightly-integrated with their hardware couldn't be adapted so easily when that hardware changed. When more capable 68000-series processors appeared, such as the 68030 with built-in memory management, Atari's TOS, Commodore's AmigaOS and Apple's MacOS couldn't use it. They could only use the new CPU as a faster 68000.
This is the trap that RISC OS is in. Amazingly, by being a small fish in a very small pond -- and thanks to Castle's mysterious one big customer -- it has survived into its fourth decade. The only other end-user OS to survive since then has been NeXTstep, or macOS as it's now called, and it's had a total facelift and does not resemble its 1980s incarnation at all: a 32-bit 68030 OS became a PowerPC OS, which became an Intel 32-bit x86 OS, which became a 64-bit x86 OS and will soon be a 64-bit ARM OS. No 1980s or 1990s NeXTstep software can run on macOS today.
When ARM chips went 32-bit only, RISC OS needed an extensive rewrite, and all the 26-bit apps stopped working. Now, ARM chips are 64-bit, and soon, the high-end models will drop 32-bit support altogether.
As Wimp2 showed, if RISC OS's multitasking module was replaced with a pre-emptive one, a lot of existing apps would stop working.
AmigaOS is now owned by a company called Hyperion, who have ported it to PowerPC -- although there aren't many PowerPC chips around any more.
It's too late for virtual memory, and we don't really need it any more -- but the programming methods that allow virtual memory, letting programs spill over onto disk if the OS runs low on memory, are the same as those that enforce the protection of each program's RAM from all other programs.
Just like Apple did in the late 1990s, Hyperion have discovered that if they rewrite their OS to take advantage of PowerPC chips' hardware memory-protection, then it breaks all the existing apps whose programmers assumed that they could just read and write whatever memory they wanted. That's how Amiga apps communicate with the OS -- it's what made AmigaOS so small and fast. There are no barriers between programs -- so when one program crashes, they all crash.
The same applies to RISC OS -- although it does some clever trickery to hide programs' memory from each other, they can all see the memory that belongs to the OS itself. Change that, and all existing programs stop working.
To make RISC OS able to take advantage of multiple processors, the core OS itself needs an extensive rewrite to allow all its modules to be re-entrant -- that is, for different apps running on different cores to be able to call the same OS modules at the same time and for it to work. The problem is that the design of the RISC OS kernel dates back to about 1981 and a single eight-bit 6502 processor. The assumption that there's only one processor doing one thing at a time is deeply written into it.
That can be changed, certainly -- but it's a lot of work, because the original design never allowed for this. And once again, all existing programs will have to be rewritten to work with the new design.
Linux, to pick an example, focuses on source code compatibility. Since it's open source, and all its apps are open source, then if you get a new CPU, you just recompile all your code for the new chip. Linux on a PowerPC computer can't run x86 software, and Linux on an ARM computer can't run PowerPC software. And Linux on a 64-bit x86 computer doesn't natively support 32-bit software, although the support can be added. If you try to run a commercial, proprietary, closed-source Linux program from 15 or 20 years ago on a modern Linux, it won't even install and definitely won't function -- because all the supporting libraries and modules have slowly changed over that time.
Windows does this very well, because Microsoft have spend tens of billions of dollars on tens of thousands of programmers, writing emulation layers to run 16-bit code on 32-bit Windows, and 32-bit code on 64-bit Windows. Windows embeds layers of virtualisation to ensure that as much old code as possible will still work -- only when 64-bit Vista arrived in 2006 did Windows finally drop support for DOS programs from the early 1980s. Today, Windows on ARM computers emulates an x86 chip so that PC programs will still work.
In contrast, every few versions of macOS, Apple removes any superseded code. The first x86 version of what was then called Mac OS X was 10.4, which was also the last version that ran Classic MacOS apps. By version 10.6, OS X no longer ran on PowerPC Macs, and OS X 10.7 no longer ran PowerPC apps. OS X 10.8 only ran on 64-bit Macs, and 10.15 won't run 32-bit apps.
This allows Apple to keep the OS relatively small and manageable, whereas Microsoft is struggling to maintain the vast Windows codebase. When Windows 10 came out, it announced that 10 was the last-ever major new version of Windows.
It would be possible to rewrite RISC OS to give it pre-emptive multitasking -- but either all existing apps would need to be rewritten, or it would need to incorporate some kind of emulator, like Aemulor, to run old apps on the new OS.
Pre-emptive multitasking -- which is a little slower -- would make multi-threading a little easier, which in turn would allow multi-core support. But that would need existing apps to be rewritten to use multiple threads, which allows them to use more than one CPU core at once. Old apps might still work, but not get any faster -- you could just run as many as you have CPU cores side-by-side with only a small drop in speed.
Then a rewrite of RISC OS for 64-bit ARM chips would require a 32-bit emulation layer for old apps to run -- and very slowly at that, when ARM chips no longer execute 32-bit code directly. A software emulation of 32-bit ARM would be needed, with perhaps a 10x performance drop.
All this, on a codebase that was never intended to allow such things, and done by a tiny crew of volunteers. It will take many years. Each new version will inevitably lose some older software which will stop working. And each year, some of those old enthusiasts who are willing to spend money on it will die. I got my first RISC OS machine in 1989, when I was 21. I'm 52 now. People who came across from the previous generation of Acorn computers, the BBC Micro, are often in their sixties.
Once the older users retire, who will spend money on this? Why would you, when you can use Linux, which does far more and is free. Yes, it's slower and it needs a lot more memory -- but my main laptop is from 2011, cost me £129 second-hand in 2017, and is fast and reliable in use.
To quote an old joke:
"A traveller stops to ask a farmer the way to a small village. The farmer thinks for a while and then says "If you want to go there I would not start from here."
There are alternative approaches. Linux is one. There's already a RISC OS-like desktop for Linux: it's called ROX Desktop, and it's very small and fast. It needs a bit of an update, but nothing huge.
ROX has its own system for single-file applications, like RISC OS's !Apps, called 0install -- but this never caught on. However, there are others -- my personal favourite is called AppImage, but there are also Snap apps and Flatpak. Supporting all of them is perfectly doable.
There is also an incomplete tool for running RISC OS apps on Linux, called ROLF... and a project to run RISC OS itself as an app under Linux.
Not all Linux distributions have the complicated Linux directory layout -- one of my favourites is GoboLinux, which has a much simpler, Mac-like layout.
It would be possible to put together a Linux distribution for ARM computers which looked and worked like RISC OS, had a simple directory layout like RISC OS, including applications packaged as single files, and which, with some work, could run existing RISC OS apps.
No, it wouldn't be small and fast like RISC OS -- it would be nearly as big and slow as any other Linux distro, just much more familiar for RISC OS users. This is apparently good enough for all the many customers of Virtual Acorn, who run RISC OS on top of Windows.
But it would be a lot easier to do than the massive rewrite of RISC OS needed to bring it up to par with other 21st century OSes -- and which would result in a bigger, slower, more complex RISC OS anyway.
The other approach would be to ignore Linux and start over with a clean sheet. Adopt an existing open-source operating system, modify it to look and work more like RISC OS, and write some kind of emulator for existing applications.
My personal preference would be A2/Bluebottle, which is the step-child of what Acorn originally wanted as the OS for the Archimedes. It would need a considerable amount of work, but Professor Wirth designed the system to be tiny, simple and easy to understand. It's written in a language that resembles Delphi. It's still used for teaching students at ETH Zürich, and is very highly-regarded [PDF] in academic circles.
It would be a big job -- but not as big a job as rewriting RISC OS...
But after I left university and got a job, I bought myself my first "proper" computer: an Acorn Archimedes. The Archie remains one of the most beautiful computers [PDF] to use and to program I've ever known. This was the machine for which Acorn developed the original ARM chip. Acorn also had am ambitious project to develop a new, multitasking, better-than-Unix OS for it, written in Modula-2 and called ARX. It never shipped, and instead, some engineers from Acorn's in-house AcornSoft publishing house did an inspired job of updating the BBC Micro OS to run on the new ARM hardware. The result was called Arthur. Version 2 was renamed RISC OS [PDF].
(Incidentally, Dick Pountain's wonderful articles about the Archie are why I bought one and why I'm here today. Some years later, I was lucky enough to work with him on PC Pro magazine and we're still occasionally in touch. A great man and a wonderful writer.)
Seven or eight years ago on a biker mailing list, Ixion, I mentioned RISC OS as something interesting to do with a Raspberry Pi, and a chap replied "a friend of mine wrote that!" Some time later, that passing comment led to me facilitating one of my favourite talks I ever attended at the RISC OS User Group of London. The account is well worth a read for the historical context.
(Commodore had a similar problem: the fancy Commodore Amiga Operating System, CAOS, was never finished, and some engineers hastily assembled a replacement around the TRIPOS research OS. That's what became AmigaOS.)
Today, RISC OS runs on a variety of mostly small and inexpensive ARM single-board computers: the Raspberry Pi, the BeagleBoard, the (rather expensive) Titanium, the PineBook and others. New users are discovering this tiny, fast, elegant little OS and becoming enthusiastic about it.
And that's let to two different but cooperating initiatives that hope to modernise and update this venerable OS. One is backed by a new British company, RISC OS Developments, who have started with a new and improved distribution of the Raspberry Pi version called RISC OS Direct. I have it running on a Rasπ 3B+ and it's really rather nice.
The other is a German project called RISC OS Cloverleaf.
What I am hoping to do here is to try to give a reality check on some of the more ambitious goals for the original native ARM OS, which remains one of my personal favourites to this day.
Even back in 1987, RISC OS was not an ambitious project. At heart, it vaguely resembles Windows 3 on top of MS-DOS: underneath, there is a single-tasking, single-user, text-mode OS built to an early-1980s design, and layered on top of that, a graphical desktop which can cooperatively multitask graphical apps -- although it can also pre-emptively multitask old text-mode programs.
Cooperative multitasking is long gone from mainstream OSes now. What it means is that programs must voluntarily surrender control to the OS, which then runs the next app for a moment, then when that app gives up control of the computer, a third, a fourth and so on. It has one partial advantage: it's a fairly lightweight, simple system. It doesn't need much hardware assistance from the CPU to work well.
But the crucial weakness is in the word "cooperative": it depends on all the programs being good citizens and behaving themselves. If one app grabs control of the computer and doesn't let go, there's nothing the OS can do. Good for games and for media playback -- unless you want to do something else at the same time, in which case, tough luck -- but bad news if an app does something demanding, like rendering a complex model or applying a big filter or something. You can't switch away and get on with anything else; you just have to wait and hope the operation finishes and doesn't run out of memory, or fill up the hard disk, or anything. Because if that one app crashes, then the whole computer crashes, too, and you'll lose all your work in all your apps.
Classic MacOS worked a bit like this, too. There are good reasons why everyone moved over to Windows 95 (or Windows NT if they could afford a really high-end PC) -- because those OSes used the 32-bit Intel chips' hardware memory protection facilities to isolate programs from one another in memory. If one crashed, there was a chance you could close down the offending program and save your work in everything else.
Unlike under MacOS 7, 8 or 9, or under RISC OS. Which is why Acorn and Apple started to go into steep decline after 1995. For most people, reliability and robustness are worth an inferior user experience and a bit of sluggishness. Nobody missed Windows 3.
Apple tried to write something better, but failed, and ended up buying NeXT Computer in 1996 for its Unix-based NeXTstep OS. Microsoft already had an escape plan -- to replace its DOS-based Windows 9x and get everyone using a newer, NT-based OS.
Acorn didn't. It was working on another ill-fated all-singing, all-dancing replacement OS, Galileo, but like ARX, it was too ambitious and was never finished. I've speculated about what might have happened if Acorn did a deal with Be for BeOS on this blog before, but it would never have happened while Acorn was dreaming of Galileo.
So Acorn kept working on RISC OS alongside its next-gen RISC PC, codenamed Phoebe: a machine with PCI slots and the ability to take two CPUs -- not that RISC OS could use more than one. It added support for larger hard disks, it built-in video encoding and decoding and some other nice features, but it was an incremental improvement at best.
Meanwhile, RISC OS had found another, but equally doomed, niche: the ill-fated Network Computer initiative. NCs were an idea before their time: thin, lightweight, simple computers with no hard disk, but always-on internet access. Programs wouldn't -- couldn't -- get installed locally: they'd just load over the Internet. (Something like a ChromeBook with web apps, 20 years later, but with standalone programs.) The Java cross-platform language was ideal for this. For this, Acorn licenced RISC OS to Pace, a UK company that made satellite and cable-TV set-top boxes.
Acorn's NC was one of the most complete and functional, although other companies tried, including DEC, Sun and Corel. The Acorn NC ran NCOS, based on, but incompatible with, RISC OS. Sadly, the NC idea was ahead of its time -- this was before broadband internet was common, and it just wasn't viable on dial-up.
Acorn finally acknowledged reality and shut down its workstation division in 1998, cancelling the Phoebe computer after production of the cases had begun. Its ARM division went on to become huge, and the other bits were sold off and disappeared. The unfinished RISC OS 4 was sold off to a company called RISC OS Ltd. (ROL), who finished it and sold it as an upgrade for existing Acorn owners. Today, it's owned by 3QD, the company behind the commercial Virtual Acorn emulator.
A different company, Castle Technology, continued making and selling some old Acorn models, until 2002 when it surprised the RISC OS world with a completely new machine: the Iyonix. It had proved impossible to make new ARM RISC OS machines, because RISC OS ran in 26-bit mode, and modern ARM chips no longer supported this. Everyone had forgotten the Pace NC effort, but Castle licenced Pace's fork of RISC OS and used it to create a new, 32-bit version for a 600MHz Intel ARM chip. It couldn't directly run old 26-bit apps, but it was quite easy to rewrite them for the new, 32-bit OS.
The RISC OS market began to flourish again in a modest way, selling fast, modern RISC OS machines to old RISC OS enthusiasts. Some companies still used RISC OS as well, and rumour said that a large ongoing order for thousands of units from a secret buyer is what made this worthwhile for Castle.
ROL, meantime, was very unhappy. It thought it had exclusive rights to RISC OS, because everyone had forgotten that Pace had a license too. I attempted to interview its proprietor, Paul Middleton, but he was not interested in cooperating.
Meantime, RISC OS Ltd continued modernising and improving the 26-bit RISC-OS-4-based branch of the family, and selling upgrades to owners of old Acorn machines.
So by early in the 21st century, there were two separate forks of RISC OS:
- ROL's edition, derived from Acorn's unfinished RISC OS 4, marketed as Select, Adjust and finally "RISC OS SIX", running on 26-bit machines, with a lot of work done on modularising the codebase and adding a Hardware Abstraction Layer to make it easier to move to different hardware. This is what you get with VirtualAcorn.
- And Castle's edition, marketed as RISC OS 5, for modern 32-bit-only ARM computers, based on Pace's branch as used to create NCOS. This is the basis of RISC OS Open and thus RISC OS Direct.
Both are still the same OS, though, with the same cooperative multitasking model. RISC OS does not have the features that make 1990s 32-bit OSes (such as OS/2 2, Windows NT, Apple Mac OS X, or the multiple competing varieties of Unix) more robust and stable: hardware-assisted memory management and memory protection, pre-emptive multitasking, support for multiple CPUs in one machine, and so on.
There are lightweight, simpler OSes that have these features -- the network-centric successor to Unix, called Plan 9, and its processor-independent successor, Inferno; the open-source Unix-like microkernel OS, Minix 3; the commercial microkernel OS, QNX, which was nearly the basis for a next-generation Amiga and was the basis of the next-generation Blackberry smartphones; the open-source successor to BeOS, Haiku; Pascal creator Niklaus Wirth's final project, Oberon, and its multiprocessor-capable successor A2/Bluebottle -- which ironically is pretty much exactly what Acorn ARX set out to be.
In recent years, RISC OS has gained some more minor modern features. It can talk to USB devices. It speaks Internet protocol and can connect to the Web. (But there's no free Wifi stack, so you need to use a cable. It can't talk Bluetooth, either.) It can handle up to 2GB of memory -- four thousand times more than my first Archimedes.
Some particular versions or products have had other niceties. The proprietary Geminus allowed you to use multiple monitors at once. Aemulor allows 32-bit computers to run some 26-bit apps. The Viewfinder add-on adaptor allowed RISC PCs to use ATI AGP graphics cards from PCs, with graphics acceleration. The inexpensive PineBook laptop has Wifi support under RISC OS.
But these are small things. Overcoming the limitations of RISC OS would be a lot more difficult. For instance, Niall Douglas implemented a pre-emptive multitasking system for RISC OS. As the module that implements cooperative multitasking is called the WIMP, he called his Wimp2. It's still out there, but it has drawbacks -- the issues are discussed here.
And the big thing that RISC OS has is legacy. It has some 35 years of history, meaning many thousands of loyal users, and hundreds of applications, including productivity apps, scientific, educational and artistic tools, internet tools, games, and more.
Sibelius, generally regarded as the best tool in the world for scoring and editing sheet music, started out as a RISC OS app.
People have a lot of investment in RISC OS. If you have using a RISC OS app for three decades to manage your email, or build 3D models, or write or draw or paint or edit photos, or you've been developing your own software in BBC BASIC -- well, that means you're probably quite old by now, and you probably don't want to change.
There are enough such users to keep paying for RISC OS to keep a small market going, offering incremental improvements.
But while if someone can raise the money to pay the programmers, adding wifi, or Bluetooth, or multi-monitor graphical acceleration, or hardware-accelerated video encoding or decoding, would be relatively easy to do, it still leaves you with a 1980s OS design:
- No pre-emptive multitasking
- No memory protection or hardware-assisted memory management
- No multi-threading or multiple CPU support
- No virtual memory, although that's less important as a £50 computer now has four times more RAM than RISC OS can support.
- Unable to take full advantage of modern hardware.
- Unreliable -- especially under heavy load.
- Unable to scale up to more processors or more memory.
The result is something way smaller and faster than big lumbering modular PC operating systems which have to work with a huge variety of hardware from hundreds of different companies -- so the OS is not closely integrated with the hardware. But conversely, this design has advantages, too: because it is adaptable to new devices, as the hardware improves, the OS can improve.
So when you ran Windows 3 on a 386 PC with 4MB of RAM -- a big deal in 1990! -- it could use the hardware 16-bit virtualisation of the 386 processor to pretend to be 2, 3 or 4 separate DOS PCs at the same time -- so you could keep your DOS apps when you moved to Windows. They didn't look or feel like Windows apps, but you already knew how to use them and you could still access all your data and continue to work with it.
Then when you got a 486 in 1995 (or a Pentium with Windows NT if you were rich) it could pretend to be multiple 386 computers running separate copies of 16-bit Windows as well as still running those DOS apps. And it could dial into the Internet using new 32-bit apps, too. By the turn of the century, it could use broadband -- the apps didn't know any difference, as it was all virtualised. Everything just went faster.
Six or seven years after that, your PC could have multiple cores, but multiple 32-bit apps could be divided up and run across two or even four cores, each one at full speed, as if it had the computer to itself. Then a few years later, you could get a new 64-bit PC with 64-bit Windows, which could still pretend to be a 32-bit PC for 32-bit apps.
When these things started to appear in the 1990s, the smaller OSes that were more tightly-integrated with their hardware couldn't be adapted so easily when that hardware changed. When more capable 68000-series processors appeared, such as the 68030 with built-in memory management, Atari's TOS, Commodore's AmigaOS and Apple's MacOS couldn't use it. They could only use the new CPU as a faster 68000.
This is the trap that RISC OS is in. Amazingly, by being a small fish in a very small pond -- and thanks to Castle's mysterious one big customer -- it has survived into its fourth decade. The only other end-user OS to survive since then has been NeXTstep, or macOS as it's now called, and it's had a total facelift and does not resemble its 1980s incarnation at all: a 32-bit 68030 OS became a PowerPC OS, which became an Intel 32-bit x86 OS, which became a 64-bit x86 OS and will soon be a 64-bit ARM OS. No 1980s or 1990s NeXTstep software can run on macOS today.
When ARM chips went 32-bit only, RISC OS needed an extensive rewrite, and all the 26-bit apps stopped working. Now, ARM chips are 64-bit, and soon, the high-end models will drop 32-bit support altogether.
As Wimp2 showed, if RISC OS's multitasking module was replaced with a pre-emptive one, a lot of existing apps would stop working.
AmigaOS is now owned by a company called Hyperion, who have ported it to PowerPC -- although there aren't many PowerPC chips around any more.
It's too late for virtual memory, and we don't really need it any more -- but the programming methods that allow virtual memory, letting programs spill over onto disk if the OS runs low on memory, are the same as those that enforce the protection of each program's RAM from all other programs.
Just like Apple did in the late 1990s, Hyperion have discovered that if they rewrite their OS to take advantage of PowerPC chips' hardware memory-protection, then it breaks all the existing apps whose programmers assumed that they could just read and write whatever memory they wanted. That's how Amiga apps communicate with the OS -- it's what made AmigaOS so small and fast. There are no barriers between programs -- so when one program crashes, they all crash.
The same applies to RISC OS -- although it does some clever trickery to hide programs' memory from each other, they can all see the memory that belongs to the OS itself. Change that, and all existing programs stop working.
To make RISC OS able to take advantage of multiple processors, the core OS itself needs an extensive rewrite to allow all its modules to be re-entrant -- that is, for different apps running on different cores to be able to call the same OS modules at the same time and for it to work. The problem is that the design of the RISC OS kernel dates back to about 1981 and a single eight-bit 6502 processor. The assumption that there's only one processor doing one thing at a time is deeply written into it.
That can be changed, certainly -- but it's a lot of work, because the original design never allowed for this. And once again, all existing programs will have to be rewritten to work with the new design.
Linux, to pick an example, focuses on source code compatibility. Since it's open source, and all its apps are open source, then if you get a new CPU, you just recompile all your code for the new chip. Linux on a PowerPC computer can't run x86 software, and Linux on an ARM computer can't run PowerPC software. And Linux on a 64-bit x86 computer doesn't natively support 32-bit software, although the support can be added. If you try to run a commercial, proprietary, closed-source Linux program from 15 or 20 years ago on a modern Linux, it won't even install and definitely won't function -- because all the supporting libraries and modules have slowly changed over that time.
Windows does this very well, because Microsoft have spend tens of billions of dollars on tens of thousands of programmers, writing emulation layers to run 16-bit code on 32-bit Windows, and 32-bit code on 64-bit Windows. Windows embeds layers of virtualisation to ensure that as much old code as possible will still work -- only when 64-bit Vista arrived in 2006 did Windows finally drop support for DOS programs from the early 1980s. Today, Windows on ARM computers emulates an x86 chip so that PC programs will still work.
In contrast, every few versions of macOS, Apple removes any superseded code. The first x86 version of what was then called Mac OS X was 10.4, which was also the last version that ran Classic MacOS apps. By version 10.6, OS X no longer ran on PowerPC Macs, and OS X 10.7 no longer ran PowerPC apps. OS X 10.8 only ran on 64-bit Macs, and 10.15 won't run 32-bit apps.
This allows Apple to keep the OS relatively small and manageable, whereas Microsoft is struggling to maintain the vast Windows codebase. When Windows 10 came out, it announced that 10 was the last-ever major new version of Windows.
It would be possible to rewrite RISC OS to give it pre-emptive multitasking -- but either all existing apps would need to be rewritten, or it would need to incorporate some kind of emulator, like Aemulor, to run old apps on the new OS.
Pre-emptive multitasking -- which is a little slower -- would make multi-threading a little easier, which in turn would allow multi-core support. But that would need existing apps to be rewritten to use multiple threads, which allows them to use more than one CPU core at once. Old apps might still work, but not get any faster -- you could just run as many as you have CPU cores side-by-side with only a small drop in speed.
Then a rewrite of RISC OS for 64-bit ARM chips would require a 32-bit emulation layer for old apps to run -- and very slowly at that, when ARM chips no longer execute 32-bit code directly. A software emulation of 32-bit ARM would be needed, with perhaps a 10x performance drop.
All this, on a codebase that was never intended to allow such things, and done by a tiny crew of volunteers. It will take many years. Each new version will inevitably lose some older software which will stop working. And each year, some of those old enthusiasts who are willing to spend money on it will die. I got my first RISC OS machine in 1989, when I was 21. I'm 52 now. People who came across from the previous generation of Acorn computers, the BBC Micro, are often in their sixties.
Once the older users retire, who will spend money on this? Why would you, when you can use Linux, which does far more and is free. Yes, it's slower and it needs a lot more memory -- but my main laptop is from 2011, cost me £129 second-hand in 2017, and is fast and reliable in use.
To quote an old joke:
"A traveller stops to ask a farmer the way to a small village. The farmer thinks for a while and then says "If you want to go there I would not start from here."
There are alternative approaches. Linux is one. There's already a RISC OS-like desktop for Linux: it's called ROX Desktop, and it's very small and fast. It needs a bit of an update, but nothing huge.
ROX has its own system for single-file applications, like RISC OS's !Apps, called 0install -- but this never caught on. However, there are others -- my personal favourite is called AppImage, but there are also Snap apps and Flatpak. Supporting all of them is perfectly doable.
There is also an incomplete tool for running RISC OS apps on Linux, called ROLF... and a project to run RISC OS itself as an app under Linux.
Not all Linux distributions have the complicated Linux directory layout -- one of my favourites is GoboLinux, which has a much simpler, Mac-like layout.
It would be possible to put together a Linux distribution for ARM computers which looked and worked like RISC OS, had a simple directory layout like RISC OS, including applications packaged as single files, and which, with some work, could run existing RISC OS apps.
No, it wouldn't be small and fast like RISC OS -- it would be nearly as big and slow as any other Linux distro, just much more familiar for RISC OS users. This is apparently good enough for all the many customers of Virtual Acorn, who run RISC OS on top of Windows.
But it would be a lot easier to do than the massive rewrite of RISC OS needed to bring it up to par with other 21st century OSes -- and which would result in a bigger, slower, more complex RISC OS anyway.
The other approach would be to ignore Linux and start over with a clean sheet. Adopt an existing open-source operating system, modify it to look and work more like RISC OS, and write some kind of emulator for existing applications.
My personal preference would be A2/Bluebottle, which is the step-child of what Acorn originally wanted as the OS for the Archimedes. It would need a considerable amount of work, but Professor Wirth designed the system to be tiny, simple and easy to understand. It's written in a language that resembles Delphi. It's still used for teaching students at ETH Zürich, and is very highly-regarded [PDF] in academic circles.
It would be a big job -- but not as big a job as rewriting RISC OS...