A good article about RISC OS and the pickle it's in

See https://liam-on-linux.livejournal.com/73983.html – the writer analyze different options to modernize RISC OS, but does not suggest going 64-bit which in my opinion is the only way to enable long-time survival. I do realize it’s a major project which may not have the programmer assets it’d need, corporate or not. Being beleaguered with the “Assembler Coding Curse” it’s like a fly in amber, frozen in time.

Nevertheless, it could do with a 64-bit renewal, written in pure C. It could still be small and fast.

First, please post off topic things in aldershot.

Secund, this is REALLY incredible. Did you even read the article? Lliam lists a few things that RISC OS still does not have and why THESE PROBLEMS CAN’T BE SOLVED.

does not suggest going 64-bit

Lliam speaks of the 64bit conversion, and of its main problem: it’ll break every existing application. So the new OS will be even more different from RISC OS than RISC OS is different from BBC MOS.

He even suggests that if you wan’t to get something more modern, while loosing software compatibility, you have better options. For example ROX Desktop on a Linux kernel with very simple distribution (for example GoboLinux) and AppImage/SnapApps/FlatPak applications.

I designed and maintained a Linux distro a long time ago. Be sure, it’s possible to make something faster and smaller than RISC OS. Not a big deal. Really not, with KMS+Wayland/Weston.

Nevertheless, it could do with a 64-bit renewal, written in pure C. It could still be small and fast.

Ironically, Llliam explains that RISC OS is small and fast only because it’s a very crude OS.

I must admit it’s rare to see so much disinformation in one post (yours). So my answer. But you’re seems to agree with Lliam on this point:

I do realize it’s a major project which may not have the programmer assets it’d need, corporate or not.

“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. […] 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.”

Being beleaguered with the “Assembler Coding Curse” it’s like a fly in amber, frozen in time.

Once again, you did not understand the problem. The real problem is how to keep software compatibility.

Technically, if you loose compatibility, your new OS will not be RISC OS, but something inspired by RISC OS. Probably a very interesting project, but not on this forum and this website that are dedicated to RISC OS.

Would you post some Windows NT rant on a VMS website? No.

The question is how to modernise RISC OS will keeping it RISC OS. There are several ongoing projects around this (did you see we now support SATA drives, NVME drives, multi GHz devices and Wifi connexions?), other that would be some funds or developers, but 64bit is not the easiest answer, and probably even not a viable answer at all.

We have also an excellent page around this.
https://www.riscosopen.org/wiki/documentation/show/Addressing%20the%20end-of-life%20of%20AArch32

So I could simply say: thanks for the suggestion. ROOL already works on it. If you wan’t this faster, please code, donate to bounties or hire some developers.

Next!

It’s point 4 in the above article I’m rooting for, as long as it’s written in C for future updates, preemptive multitasking and (possibly) virtual memory added, legacy 26/32-bit software emulated.

The drawback here is naturally that most (?) of the productivity software were written in assembler and hence are hard to port to run in a 64-bit environment.

Taken to Aldershot (so sane people can ignore this drivel)