The problem with StubsG

@ Charlotte

…but I fear this thread is turning into every other thread.

yes it is. To get back on topic:

StubG, technically speaking, is a pain and 99% of who commented here agreed on that, however the 1% that disagreed also has good reasons for that given that the RISC OS market is still so divided between RISC OS classic and modern RISC OS.

The only question that remains is why is it that difficult for the retro user-base to upgrade their bloody SCL lol

So here is my proposal:

Let’s make an SCL auto-updater in BBC BASIC that works on every system and that can update SCL from everything: network, floppies, zips and that every 2 months just sends a reminder to the user on the Desktop saying:

“Stay at home, update SCL and save lives!”

…network, floppies, zips…

And cassette tapes.

Bah, I demand my updates on ticker tape and any new fangled thing is not real stuff but modern cxxx! :-)

Oh, bu**** that was long. Never mind here it is:

There simply has to come a point where development breaks away from the past, and takes the most effective route to supporting these machines and attracting new users.

It happened years ago, some people didn’t notice and some did. Of those that did there was a split of opinion.

This doesn’t mean that the break has to be at all acrimonious.

It was. It was also years ago. Some of us choose to push it to the back of our minds, some like Rick spent time in a countryside retreat and barely know WTF.

So, we are here and some others aren’t. There are names round here, using RO5, that I recall as being on the other side of that ancient argument. They are here now, and just as much part of the community as any other.

For what it’s worth I think Rick has it absolutely correct.
Write new or revise old software and have all the features you want.
If you can make it degrade gracefully on older machines then that’s nice, but it isn’t a requirement.

StubG? A solution to a problem that didn’t exist.¹
At the time everyone was used to newer versions of SharedC appearing and needing to be installed. Each version tended to be larger and older machines struggled a little, but that was life.

The simple fact is that where a newer, and larger, SharedC might run into problems with memory so will the program(s) that require it.

For those with active antique machines – run the retro software with the old SharedC you have.
For those with new machines, the update of the ROM and HD4 will keep you current. Enjoy, but remember – soon your RPi 1 will be too old to run the latest releases, but you won’t care because the RPi 5, 6, or 7 runs them fine and has an emulator for the RPC and A4xx era software.

Concentrate on the now and tomorrow folks, and as Charlotte says
" …are increasingly fraught attempts to retain interoperability between retro and modern hardware really the way to go when emulators are available?"

¹ I’m used to seeing “solutions looking for a problem” at work². In this instance it was a faction that didn’t want to use stuff from the other side of the fence. Not using the ROL Toolbox was the equivalent from the other faction.

The only question that remains is why is it that difficult for the retro user-base to upgrade their bloody SCL lol

I think the topic deviated because that is indeed the question, and there’s no reasonable response.

People who wish to use modern software ought to have an equally modern CLib.
That’s about the size of it.

Let’s make an SCL auto-updater

What’s wrong with SysMerge? Just update !System, reboot, job done.

“Stay at home, update SCL and save lives!”

I saw a sweatshirt that said “Stay @ 127.0.0.1, don’t be 255.255.255.255”. I liked that.

and thus not leave them out.

The real world does not work like that.
And in places where there are options such as extended life support (for corporates etc), it’s very much a case of “you can have it if you pay for it”.

There are people that do not update there computer until there is a very very good reason to.

I agree. I still use XP.
That said, I accept that the rest of the world has moved on, so I don’t have much new software that works on my old OS. It’s actually pretty unreasonable to expect that in this day and age. Just as it is unreasonable to expect people writing software now to even think about support for RISC OS 3.11.

It’s pretty simple really – if you want to use an old machine, use appropriately old software. If you want to use new software, use an appropriately newer machine.

Please NO. Auto updater,

Auto updater ONLY if it is user interactive. That is to say, like Manga, it will notify of an update, but you must choose whether or not to actually perform the update.

When I set up my tablet (for the second time), I had to install Firefox twice. I’m using 63.0 (aka the not-broken one) and forgot to turn off the auto-update nonsense. So it obligingly did so, and gave me the latest (broken) Firefox. Alas, you cannot downgrade Android apps. So I had to delete it, then reinstall 63.0 and then the add-ons. <sigh>

Automatic notifications, okay.
Automatic updates, not okay.
Automatic updates that you have no control over, very much not okay.

The latter, incidently, is also used by HP from time to time to push out updates aimed at “detecting” clone cartridges. I really don’t buy the “clone inks wreck the print heads” excuse, given that the print heads are part of the cartridge…
[and, from experience being an Instant Ink subscriber and thus receiving those huge cartridges, HP’s print heads are quite capable of messing themselves up with the correct ink…]

There’s a difference between a vicious interpersonal battle which was massively inflamed by the copyright dispute, and simply producing two separate versions for two very different classes of machine.

and simply producing two separate versions for two very different classes of machine.

How would that be done, though? If we’re talking 26 bit vs 32 bit, then it implies a possible duality of all of the libraries used; plus having both kept up to date and/or bugfixed appropriately; plus the problem of how to handle code divergence.

A good example here is amusingly provided by StubsG – the available version does not support the more recent C functions ¹, something it does support behaves differently, and perhaps most importantly, two of the supplied 32 bit libraries have serious problems (lots of 26 bit code within).

¹ I’m aware that a more recent version does, and maybe even fixes the libraries, however as it isn’t easily available…

And I thought there is a project to update RISC OS 3.11 with up to date components in the ROM, making a RISC OS 3.2x for the future of Archimedes ARMv2 users.

Jon Abbott.