AMCOG Software Update: Stunt Drivers & RDSP

I go into VRPC; highlight some text in a writable icon; press ^C; return to this Chrome page in Windows and press ^V; the copied text appears. You still can’t do that in RO5

I thought it took something in the way of modification to get RO5 to run in VRPC.

You are starting from a false premise, Rick – that ensuring compatibility holds everyone back.

What’s clear from what you have written is that you are looking at this from the point of the operating system, not the application author.
In general RISC OS is stuck with an API that has had all sorts of cruft bodged in (for better or worse). However none of this is any use when it’s a new or extended feature that one wishes to make use of. For example Unicode. I was quite surprised to discover that RISC OS 4 (6?) cannot, given that I had a softloaded Unicode font manager on 3.7. But there you go.

Do you remember when the RiscPC was new and suddenly a lot of things used “deep sprites” and/or dynamic areas? It required ingenious solutions to get any of those things working on the older systems.

As to the topic in question, rather than having one unofficial-but-it-works way of doing something, turns out that the closed source branch went and did something different. So now there would be two different things to support.

Windows 10 can run programs written 20 years ago… but few programs written in 2019 are going to target the Win95 API.

That’s pretty much my point. Given 26/32 neutral code, RISC OS 5 will happily run a program that runs on an A3000. But nobody these days writes code for the ARM2/3 builds of RISC OS. They’re too old, things have moved on, right?
Well I’m in the camp of applying that logic to the ROLtd versions of RISC OS. I won’t intentionally make software incompatible, but if there’s a new API that does what I want, I’ll use it.

Service Call they replaced it with is worse, not better, and not an API I’d like to see adopted. […] interception of OS_Word,7 sort of works, in some cases, but is clearly not the right approach

Which leads to the obvious question of what would be a proper approach (and, hey, look, there are now three APIs!).

in some ways, more polished

In a lot of ways it is more polished. ROLtd concentrated on new features, Castle concentrated on new hardware. Ultimately sticking with the same hardware was going to be an evolutionary dead end, however the Select subscription scheme was intended to provide an ever increasing feature set to the users. A lot of the work that goes into version 5 is not cosmetic. Bug fixes, of course, but also additional hardware support. 5 new supports more different hardware types than Acorn ever did, with a plethora of different SoCs from different chip bakers, each with their own quirks and drivers. By and large the application level API presented is the same across the lot of them. Not identical (BGR vs RGB and lack of 16 colour modes) but very similar. Sure, it is embarrassing that proper cut and paste (like every other OS) isn’t available on 5, however on the flip side you have a half dozen Pi boards, about as many OMAP boards, and things such as Ti and iMX6 to choose from. You can get a great RISC OS setup for under a grand (still cheaper than Acorn!) or you can roll a usable one for forty quid and some salvaged parts. Perhaps that’s worth more than working cut and paste? That’s not to say that it wouldn’t be nice to have, but there aren’t many developers actively working on 5 so it’s a question of priorities…

You still can’t do that in RO5.

I can run RISC OS native on contemporary devices drawing practically no power at all. Can’t do that with……. ;-)

You are starting from a false premise, Rick – that ensuring compatibility holds everyone back. It doesn’t, but it should guide design and implementation.

Ensuring compatibility costs time and effort, and hence it holds back everything and everyone by adding delays. You can only decide on a case-by-case basis if it is worth the time and effort. And that decision can only be done in an informed way if the one having to decide knows basically everything, from BBC MOS till RISC OS 5 and 6. Even Acorn’s own RISC OS engineers made wrong decisions back in the day, so it is certainly not an easy thing to do.

Personally, I have been a part-time RISC OS developer since RISC OS 2 times, but I couldn’t offer an informed opinion on most of the implementation decisions chosen for the many backward compatibility breaking changes that surfaced over time. The last really disturbing change was probably the slight change in behaviour wrt image filing system handling that broke SparkFS. This was fixed by changing SparkFS instead of rolling back the OS change without further discussion of the impact on other image filing systems – and it still frightens me how much fallout this will create in the future.

At least the SparkFS problem was only caused by unclear documentation that the two parties had interpreted differently.