RISC OS, the operating system from the United Kingdom originally designed to run on Acorn Computer’s Archimedes computers – the first ARM computers – is still actively developed today. Especially since the introduction of the Raspberry Pi, new life was breathed into this ageing operating system, and it has gained quite a bit of steady momentum ever since, with tons of small updates, applications, and new hardware support, including things like support for wireless networking. This development has always been a bit piecemeal, though, and the pace has never been exceptionally fast.
Now, though, time really is ticking for RISC OS: popular RISC OS platforms like the Raspberry Pi are moving to 64bit ARM only, and this poses a big problem for RISC OS: most of it is written in pure 32bit ARM assembly. As you can imagine, the supply of capable 32bit ARM boards is going to dwindle over the coming years, which would put RISC OS right back where it was before the launch of the Raspberry Pi: floundering, relying on old hardware. This is obviously not ideal, and as such, RISC OS Open Limited wants to take a big leap to address this.
Since 2011, ROOL has successfully delivered dozens of community-funded improvements through its bounty scheme. While this model has enabled steady progress, it is not suited to the scale of work now required to modernise RISC OS. The Moonshots initiative represents a fundamental shift: focused, multi-year development projects undertaken by full-time engineers.
The first Moonshot aims to make the RISC OS source code portable and compatible with 64-bit Arm platforms, a prerequisite for future hardware support. ROOL has already scoped the work, identified key milestones, and built cost models based on realistic employment and project management needs.
↫ Steve Revill in a ROOL press release
They’re going to need a dedicated team of several developers working over the course of several years to port RISC OS to 64bit ARM. That’s going to require quite a bit of money, manpower, and expertise, and considering ROOL has only collected about £100000 worth of donations over the past 14 years, I can see why they’re aiming to go big for this effort. All these giant technology corporations with trillion dollar stock valuations are currently relying on ARM technology, so you’d think they could empty a few socks and cough up a few million to get this effort funded properly, but alas, we all know that’s not going to happen.
I hope ROOL can make this work. RISC OS is a ton of fun to use, and occupies a unique place in computing history. I would be incredibly sad to see technological progress leave it behind, when what amount to chump change for so many wealthy companies and individuals could save it.
I wish them luck but I am not sure what ARM related company would be interested. Who makes money on ARM? Apple? Google? Samsung? A competing OS is not only not useful, it could be seen as against their interests. Qualcomm? MediaTek?
The most obvious candidates would be ARM themselves or the Raspberry Pi Foundation I suppose. They do not really benefit much either though.
It is always great to see Open Source continue. RISCOS is a fairly minimal OS. Perhaps it wouldn’t be too hard. A rewrite into something more portable would be better but maybe more work.
That said, not every OS has to live forever. The DOS and 16 bit Windows that RISCOS was born to compete with are gone. Classic MacOS from the time is gone too. The Windows and macOS of today are totally unrelated code wise. Like the Apple II and Commodore 64, they live on through emulation.
Well said.
Small point of information…
> The DOS and 16 bit Windows that RISCOS was born to compete with are gone.
DOS is not gone. FreeDOS is alive and well and version 1.4 is in testing and due in weeks. SvarDOS is alive and well too. DOSemu2 for x86-64 also maintains its own DOS, FDPP:
https://github.com/dosemu2/fdpp
… although it can run the upstream too.
The direct ancestor of RISC OS, Acorn Arthur, was released in September 1987.
Windows 2.0 wasn’t released until December that year.
RISC OS 2.0, which is a very recognisable ancestor of the current RISC OS 5, was released in April 1989, more than a year before Windows 3.0, which came out in May 1990.
So the key releases of RISC OS are from _before_ the key releases of Windows.
Arthur was almost a tech demo, but it was a pretty impressive and influential tech demo. For instance, it already featured the RISC OS “icon bar”, and it was out about one _year_ before the first public demo of NextStep, which was 0.8 in October 1988. I have interviewed Paul Fellows, the project lead on the original RISC OS, and he adamantly maintains that NeXT got the idea from RISC OS. He can name the Acorn engineer who quit and moved to Silicon Valley to work for NeXT — and that developer took his Archimedes with him.
https://www.theregister.com/2022/06/23/how_risc_os_happened/
https://www.youtube.com/watch?v=P_SDL0IwbCc
I think it’s important to remember the chronology. It’s all documented history.
Yes, DOS outcompeted CP/M-86, but it had more than 2 years to do it, because DR was really late. That matters more than where Kildall was or who talked to IBM
Yes, RISC OS competed with Windows 2, but it came first.
Yes, NeXTstep popularised the dock, but it was the _second_ OS with one to be seen by the public.
Yes, Windows 3.0 had 3D shaded buttons, which caused a trend that swept the industry — but those window buttons came from OS/2 1.2, the year before.
https://winworldpc.com/screenshot/c3b23b57-c3a7-1b19-11c3-a4e284a2c3a5
And OS/2 got the idea of greyscale fake-3D shading from NeXTstep. The two OSes shipped at about the same time — OS/2 1.2 and NeXTstep 1.0 were only a month apart — but the demo of NeXTstep 0.8 was extremely influential. Everyone had seen it and talked about it.
There is a huge “first mover” effect in this business. For that to work you need to keep track of who was first.
> DOS is not gone.
Yes. Maybe 1000 people on the planet still use it, so it’s worth investing into.
pikaczex,
I don’t care much either way, but I suspect the number is far greater than this just in retro gaming alone not to mention old industry applications. I’ve personally worked on some of these systems – a lot of these users have the mindset of if it ain’t broke, why fix is.
@Iproven
I hesitated to say that DOS was “gone” because of FreeDOS but, for once, I was trying to keep it brief. SvarDOS was unknown to me though so thank you for bringing it up. Quite interesting that a branch of the DR-DOS family is still kicking.
DOS is in the very unusual situation that modern CPUs from Intel and AMD are still capable of running 16 bit operating systems designed for the original IBM PC. If ARM chose to continue support for 32 bit operation for decades then RISCOS would stay viable on real hardware as well.
My point was that DOS has not been ported to new architectures as is being suggested to do with RISCOS. So, while I agree with you about DOS, what I was trying to say still stands. Your own mention of DOSemu2 aligns well with my final paragraph.
I also agree with the importance of getting the timelines right. If that is the goal though, starting the Windows timeline at version 2 seems a bit tortured. If we are going to do that, shouldn’t we start RISCOS at Arthur 2.0 in 1989?
Windows 1 was released in 1985, well before RISCOS anything, and since Windows 2 was released in 1987, I think it is safe to say that RISCOS was launched as a competitor to DOS/Windows and the “System x” editions of MacOS.
I think the popular consensus on GUI timeline is that Apple (Mac) ripped off Xerox and Microsoft (Windows) ripped off Apple. It is important not to forget that much of even the current macOS UI appeared first with the Lisa in 1983. There was also GEM in 1985 and GEOS in 1986. GEM removed many GUI concepts as a result of legal threats from Apple so the influence there is pretty clear.
As you correctly allude to though, Microsoft got most of their GUI design guidelines directly from IBM’s Common User Access GUI specifications (CUA) via their OS/2 collaboration. CUA was used in multiple IBM products, including OS/2. Microsoft certainly used them to implement the Windows UI as, before 1990, the plan was that OS/2 would be what everybody was moving to next. Microsoft’s decision to leave OS/2 2.0 as an IBM only product in 1992 culminated in the launch of Windows NT in 1993 which featured the Windows 3.1 GUI (a manifestation of CUA that came from Windows 2.0 in 1987, Windows 3.0 in 1990, and Windows 3.1 in 1992).
The first published CUA spec that I am aware of is 1.0 from January 1987 though drafts and ideas certainly existed earlier. Windows 1.0 (1985) came before the full CUA but both the OS/2 GUI and Windows 2+ came after and reflect the CUA strongly. Everything Arthur and RISCOS came after the release of CUA 1.0 so I do not think we can say that either OS/2 or Windows was borrowing from RISCOS in any serious way.
As you say, you need to keep track of who was first.
That said, you could convince me that the Windows 95 task bar took inspiration from RISCOS. It is hard to know if those involved were aware of it. NextSTEP had a dock, clearly preserved in macOS X, but the start menu and Windows task bar do not feel like they sprang from NextSTEP to me. Every GUI idea ever has shown up at some point on an X11 destkop (after 1984) so it gets hard to track true “firsts” that were not significant commercially.
> If ARM chose to continue support for 32 bit operation for decades
ARM licenses designs. You pay for what you use, and many of the chips are tiny and cheap. So it saves silicon makers money to omit things they do not need. Omit Arm32 support and you both save some silicon and you save some licence fees.
This does not apply on x86, where you get all or nothing.
FWIW, I covered this here:
https://www.theregister.com/2025/04/01/risc_os_open_moonshots/
> If we are going to do that, shouldn’t we start RISCOS at Arthur 2.0 in 1989?
That is a confused mix up.
Arthur was released in 1987.
RISC OS _is_ Arthur 2. RISC OS was released in 1989. Version 2 was the first release under that name.
> GEM removed many GUI concepts as a result of legal threats from Apple
1. Only PC GEM. Atari ST GEM was unaffected.
A historical footnote, but:
2. GEM has been FOSS for about 25 years and long ago put back the missing features.
> I do not think we can say that either OS/2 or Windows was borrowing from RISCOS in any serious way.
Again, this is a confusion of ideas.
I am not saying OS/2 borrowed anything. I am not saying Windows _in general_ did but specifically _Windows 95_ did.
1. Arthur influenced NeXT.
Arthur had the icon bar (1987).
An Acorn engineer left, moved to California, and joined NeXT. He took his Archimedes with him.
The following year, NeXTstep 0.8 was demoed with the first version of the Dock.
In 1989 NeXTstep 1.0 shipped, with the Dock. It didn’t sell well but was very famous. Anyone important in the GUI space saw it.
By 1993 the early test builds of Windows “Chicago” had a prototype taskbar.
Crudely speaking, the high-level plan is:
1. Update (minimal) low-level 32-bit Arm to work on 64-bit
2. Rewrite higher-level Arm assembler modules in C
3. Update various core applications
4. Implement a 32-bit emulator for legacy code
By rewriting (and to some extent rearchitecting) the bulk of the hand-crafted Arm assembly parts into C, we’ll have better portability and a much easier codebase to build upon going forward.
sarev,
Makes sense to me.
I am more familiar with x86. Isn’t it still possible to run 32bit applications (on a 64bit ARM OS) without an emulator? Is this just for future proofing or is it already a problem today?
When you want to bring out a new Arm SoC, you can license different blocks of the architecture. Many won’t bother with 32-bit kernel mode (which RISC OS uses a lot) so you only get user mode. This is fine if you’re only concerned about running some legacy application binaries on your chip. Raspberry Pi 5 is an example of this. However, we’re increasingly seeing chips that don’t even bother with that, so there’s no 32-bit mode support at all there.
CPU vendors are actively pushing for 64-bit only CPUs. And unlike x86 world where AMD and Intel only talk about that possibility, in ARM world silicone with 32bit ISA is already typical. Many latest Android flagships don’t have it and cheaper devices use ARM64-to-ARM32 emulation to support 32bit userspace.
It’s actually pretty efficient: ARM32 have 16 registesr, but ARM64 have 32 registers and 32bit operations, too! Which means that you don’t need to do crazy complicated dance, most of the time simple static one-instruction-to-one-instruction emulator (similar to Rosetta2 or Microsoft’s ARM64EC) would work just fine.
But yes, it’s pretty real problem, not something that may happen many years down the road.
zde,
I was not aware support for 32bit ARM userspace was already being phased out on mainstream hardware without emulation. Given that’s the case, emulation becomes important.
Emulation should be relatively easy as long as the new ISA is a superset of the old one. I don’t know if there are any cases like this, but if you don’t have a 1:1 instruction mapping it could have an impact on the atomicity of the emulated instruction set. Whether or not that’s an issue would depend on whether or not the code is dependent on an instruction being indivisible like read-modify-write instructions. I don’t imagine this is a problem emulating ARM on ARM however.
Alfman,
I might be missing something, but even Intel was trying to do an “64 bit only” CPU with almost no cruft from 16 or even 32 bit days.
(I think they even wanted to redesign the fundamental bus and power architecture as well, but that could be a different story).
https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
Even if the 32-bit parts take up a small space in the CPU, every last transistor is very valuable in today’s competitive market, isn’t it?
ARM is RISC, which means it has very few atomic instructions. And while ARM32 includes multiple-load and multiple-store instructions that would have to be mapped to many instructions in ARM64 (they used up a lot of encoding space and it was needed for other things) they were non-atomic and interruptible since the day one, since ARM1 CPU!
Thus emulation of userspace ARM32 on ARM64 is very easy and straightforward… kernel space is another issue, it’s, like, entirely different world with crazy number of differences. That’s why they would have to rewrite parts of kernel.
sukru,
Yeah, I looked i up to see what the status of that is, and it appears to be canceled.
https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
https://www.tomshardware.com/pc-components/cpus/intel-terminates-x86s-initiative-unilateral-quest-to-de-bloat-x86-instruction-set-comes-to-an-end
I agree that cutting down on complexity could make sense, but it also compromises backwards compatibility which has been such a marketable advantage for x86 in particular..
32bit operating systems are uncommon today, the bigger immediate impact would probably be 64bit operating systems that rely on 16/32bit bootloading process. My understanding is that intel’s x86S architecture always intended to continue supporting 32bit userspace applications. So software like steam and tons of games that still use x86 32bit would not be impacted by x86S. In terms of the 32bit userspace emulation we’re talking about in this article, x86S would not have required it.
zde,
I’m not familiar with ARM down to the assembly level, but even ARM can’t get around the fact that higher level software primitives can depend on atomic instructions existing in the CPU.
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
It looks like ARM has supported atomic read/modify/write instructions since ARMv6, which is 32bit.
https://stackoverflow.com/questions/18475347/how-to-compare-and-swap-atomically-in-arm7
https://stackoverflow.com/questions/17733245/whats-the-corresponding-prefix-in-arm-assembly-for-lock-in-x86
So clearly these will need to be emulated atomically as well. However I don’t see that as a problem considering the 64bit CPU more than likely supports the same instructions at the hardware level.
I would imagine that all atomic ARM32 primitives can be directly mapped to atomic ARM64 primitives. However if that weren’t the case then in order to get correct atomicity semantics an emulator would have involve the scheduler at the kernel level to make sure the atomic instruction is not interrupted and furthermore that other threads that might affect the memory cannot be running simultaneously on other cores. This would likely have a negative impact on performance beyond normal emulation overhead.
@sarev
It sounds like you have some insider knowledge here. If what you say is correct, the “minimal” work to port RISCOS to 64 bit is really all that is required for RISCOS to continue into the future (eg. to run on the Raspberry Pi 5 and its successors). That sounds like great news for Thom and others hoping that RISCOS sticks around.
Porting to C should make it possible to port to other architectures which could be interesting. Depending on how the emulator is written, it may even be possible to run 32 bit ARM apps on those future architectures.
RISC-V could use another lightweight OS option. RISC-V may benefit more than ARM really. Perhaps someone in the RISC-V ecosystem could be convinced to pursue a port (funding the transition to C).
As above, I wish you luck.
Once the 64bit port is done, I want to see a port of RISC OS to Apple Silicone
Not gonna happen, I’m afraid. It’s not really possible to port it to Apple silicone once-and-for-all. Many parts of it are proprietary and only work with binary blobs that Apple dumps from time to time. Which means supporting Linux, RiscOS or any other OS on Apple Silicone is ongoing commitment with significant funding. Who would fund that and why?
zde,
Apple’s proprietary hardware was never ideal, requiring reverse engineering and faith that they won’t break anything for alternative projects. Unfortunately it’s pretty much been the status quo across ARM :-/
Such projects can conceivably continue unfunded thanks to volunteers, but that’s not necessarily reassuring for sustainability. I wouldn’t call the situation ideal, but still many FOSS projects have proven resilient despite funding difficulties.
RISC OS being written in assembly is always going to be problematic for portability. The benefits of assembly programming have become marginalized as compilers have gotten more sophisticated and CPUs have gotten more powerful and complicated. IMHO it is quite important for code to be portable so it would be prudent to reconsider the choice of assembly, but at the same time I can understand how switching languages is off putting to those who consider assembly part of the RISC OS identity.
@zde
Is it really that dire?
The Asahi Linux page makes it sound like any OS could piggy-back on their work without the target OS needing to have much Apple specific knowledge. Yes, even Asahi relies on “binary blobs” once Linux starts but these just seem to be device firmware. They just need to be loaded by the appropriate drivers. If am not sure how much “significant funding” would be required to handled the “ongoing commitment” of supporting any updated device firmware in future. I am sure staying on the older firmware would be possible even if not ideal. Any OS is going to have to have initial drivers for the hardware. There is not much getting away from that.
https://asahilinux.org/docs/platform/open-os-interop/
I am not suggesting porting RISCOS to Apple Silicon but “It’s really not possible” sounds like an overstatement assuming that RISCOS becomes portable at all.
It’s not possible to downgrade system firmware on Mac silicone device. Thus yea, Asahi Linux work would help, but someone still have to do ongoing work. And it’s not insignificant: Asahi Linux doesn’t even support M3 CPUs yet and these are already obsolete, the only ones you may buy today in Apple Store are M4!
@zde
Funny to hear you call the M3 obsolete. The nicest computer in my home by far is my wife’s M2. There are still lots of refurbished M1 machines for sale at apple.com. Of course, I get your point about Asahi (and any other OS) lagging behind on Apple Silicon.
As it happens, I am typing this on a 2009 Macbook Pro with a well and truly obsolete Core Duo processor in it. Fantastic keyboard and screen though so I have spent the morning on it setting up stuff on AWS and running PostreSQL queries for a class. With Firefox 137 installed, it was certainly no problem watching a couple YouTube videos at 1080p earlier. Kernel version 6,13.8. bcachefs 1.25. LibreOffice 25.2.2. Gimp 3.0.2. Windows 11 fonts. OpenTofu 1.9. The software on this machine is far from obsolete and, in some ways, that is more important than the hardware. Of course, if I was editing video today, I sure would want to be reaching for that M4 if I could!
How I ended up on this machine today was that I installed Chimera Linux on it this morning to see if I could get bcachefs on the root partition (success). The hardware is 100% supported out-of-the-box by Chimera and I was ok to wipe the drive so it is a perfect machine to test with. Things went well enough that I have just continued on my day without switching machines. The CPU in this machine is certainly obsolete but still useful and the rest of the machine (screen, keyboard, trackpad) remains a joy to use. Unfortunately, it allows me to waste time on OSnews just as well as a newer machine would..
LeFantome,
The problem with Asahi is that they had a public falling out, and the main developer has left the leadership role. I”m sure there are others who will pick up the mantle, but that was a real set back.
Some earlier discussions here:
https://news.ycombinator.com/item?id=36030969
Nevertheless it is an important project, and as you mentioned M3/M4 support is currently “on hold”:
https://www.howtogeek.com/asahi-linux-reorganization-m3-m4-mac-support/
> All these giant technology corporations with trillion dollar stock valuations are currently relying on ARM technology, so you’d think they could empty a few socks and cough up a few million to get this effort funded properly, but alas, we all know that’s not going to happen.
I don’t see how that is related. Yes, they use ARM. But they do not use RISC OS at all.
> I would be incredibly sad to see technological progress leave it behind,
Except that has already happend. RISC OS is not a modern OS by any means. It’s nice to tinker around with it, and Raspberry Pis on which it works will be around for long enough, as well as other platforms that support 32 bit still. E.g. the PineBook is still being sold as well. As long as hardware for it is available, it’s all fine – it doesn’t need the newest hardware.
The problem is with “as long as hardware for it is available”. 32bit ARM in hardware is quickly becoming the dying option. Even Android uses software emulation of 32bit ARM or 64bit ARM. It’s a bit silly, but that’s the world we live it. If RISC OS wants to stay viable it would need to do the same.
Ironically enough this gives us an opportunity to restore ARM26 mode where RISC OS have started, because supporting it is not much harder than ARM32, in emulation.
But for the OS kernel… there are unique challenges, some code may be easier to rewrite than to support with emulator.
Are there any industries where RISC OS is still in service?
BeOS had some penetration into video editing and places like radio stations, so even when it went out in 2000/01 or so, you still had software like TuneTracker that depended on it — prolly one reason we saw YellowTab continue development of BeOS the same way that EComStation continues development of OS/2. There was some commercial incentive to keep the OS alive — maybe just not enough of it. And, arguably, a Wrong Company got rights to the BeOS source, etc., and could be that development of BeOS would have continued successfully if the rights had not gone to Palm and then HP.
I don’t know whether RISC OS is in a similar situation — a brief read leads me to think that, apart from its use in TV set-top boxes, there isn’t a commercial install base,
I would say, as soon as Linux becomes viable on a platform, all other alternate OSes cease to exist, at least in a viable form.
On the PC, this was easy to see. It replaced all previous UNIX brethren, starting with Minix, but including BSD, Solaris, Xenix, and others, which were prominent, or at least trying to get a foothold on the Intel platform.
It even killed momentum on FreeDOS, ReactOS, and … Windows itself. (Microsoft Azure cloud has more Linux than Windows).
The mobile? We had Windows Phone, Symbian, and others. Today we only have iOS, and Linux (Android, Tizen, and similar)
Smart TVs? Roku, Tizen are both Linux. Only LG/WebOS is there (okay, checked again it also is now Linux)
So the pattern continues. Since the ARM microcontrollers are now good with Linux (including Raspberry Pi, even the “pico”: https://github.com/Mr-Bossman/pi-pico2-linux), I don’t expect RISC OS to make a proper comeback….
Sorry….
(I really wish there were more operating systems)