Anyone got a copy of CLib v5.43?

[wmd]

If so, can you please share, or direct me to it?

[IanJeffray]

If so, can you please share, or direct me to it?

You really don't want to be using that, particularly with a RISC OS 3.1 machine, IMVHO. (RISC OS 4.39 will even moan at you for loading it...)

But if you really feel you must, I think you'll find the latest in ROOL's "System Resources" here : https://www.riscosopen.org/content/downloads/riscpc

[Sophira]

You really don't want to be using that, particularly with a RISC OS 3.1 machine, IMVHO. (RISC OS 4.39 will even moan at you for loading it...)

Out of curiosity, why is that? I've been running 5.77 with no issues on Arculator.

[wmd]

If so, can you please share, or direct me to it?

You really don't want to be using that, particularly with a RISC OS 3.1 machine, IMVHO. (RISC OS 4.39 will even moan at you for loading it...)

But if you really feel you must, I think you'll find the latest in ROOL's "System Resources" here : https://www.riscosopen.org/content/downloads/riscpc

I need it for Chuckie Egg to run on RO3.1. In the !Run file it is looking for CLib 5.43 or greater. The only version I have is the version from the System Resources you linked to (6.21). However, that version doesn't work, it just causes the game to freeze at the loading screen.

[wmd]

Out of curiosity, why is that? I've been running 5.77 with no issues on Arculator.

Any chance you could upload that version so I can test it?

[IanJeffray]

You really don't want to be using that, particularly with a RISC OS 3.1 machine, IMVHO. (RISC OS 4.39 will even moan at you for loading it...)

Out of curiosity, why is that? I've been running 5.77 with no issues on Arculator.

Why? I'm not sure. Gerph's your man to explain, but IIRC it's down to apps' expectations about how CLib implements things.

More to the point is why anything thinks it needs the newer CLib, chewing up your RMA. I rather have a feeling that it's more likely due to be "ooh shiny" than any real technical reason.

[Sophira]

I've managed to find why 5.43 is a bad idea. It seems it was a version provided by Castle for their new Iyonix machines that isn't recognised by RISCOS Ltd.

As for Chuckie Egg, wmd, one warning - arcarc.nl provides two versions, and 1.04 doesn't seem to run on RO3.11 as far as I can tell - it crashes for me with "SWI &65 not found", which suggests to me that it's designed for a Risc PC. 1.03 works, however. If the version of the game you're using uses actual anti-aliased fonts on the title screen then you're likely using 1.04+.

1.03 seems to run fine on RISC OS 3.11, however, with an appropriate version of CLib (it also checks for 5.43 or above).

And sure, here's a copy of CLib 5.77! Though bear in mind my version of it is from the retro-kit UniBoot structure so you may want to grab that too!

[wmd]

Thanks for the upload, however, the game still hangs at the loading screen for me. I don't use a boot, so nothing else is loaded. It's a mystery, as this game was working recently, but now will not. I assume it worked previously due to loading another game first that used a compatible version of CLib, but I'm not fully convinced about that. No viruses on the system either, I have the latest version of VProtect running. The version of the game I have is 1.03. I tried redownloading it (1.03) from the author's website, but still same crash.

[paintings]

I can do you two CLib versions: 5.53 (from Marutan's RISC OS 3.71 bundle for RPCEmu) and 5.47 (which I found lurking in my copy of RISC OS 4.39 for VirtualAcorn).

[rps102]

If so, can you please share, or direct me to it?

The subject line caught my eye, as I wondered what was magic about 5.43 versus just using the latest (at time of typing 6.21 09-Aug-2023). Then the penny dropped...often you'll see these 2 RMEnsures in an application's !Run file

Code: Select all

RMEnsure SharedCLibrary 5.17 RMLoad System:Modules.CLib
RMEnsure SharedCLibrary 5.34 Error This application requires SharedCLibrary 5.34 or later to run.

What that's doing is ensuring the first officially released APCS-32 supporting C Library is loaded. The seemingly odd check of 5.17 is because there were some beta releases of the module on Pace's website which escaped into the wild and you can't typically softload the C Library twice without a world of pain. My guess is 5.43 is a typo of 5.34.

Why would you need a newer C Library loaded? Well, if the application you're trying to run was compiled to run on a 32 bit version of RISC OS it'll be wanting to use APCS-32 which wasn't present in earlier modules (only APCS-R and a bit of lingering APCS-A). There's also a bunch of bug fixes along the way as well as you might expect, even if you don't care about 32 bit stuff those might be worth having.

Don't be put off by the '32 bit' bit, all that really translates to is 'functions are expected to preserve flags'. For the softloading (pre RISC OS 5) one there aren't internally 2 copies of all the library functions, that'd be silly, there's just one which happens to preserve flags. For a client which isn't expecting flag preservation (APCS-32) that it preserves flags is harmless. Therefore rather than providing 2 variants of the application often developers will just compile stuff as APCS-32 since that'd work in both flags preserving and non-flags preserving cases.

In addition, if the program is using any language features from C99, large file support, or C18, then you might see other RMEnsure numbers. They need a newer C Library because the newer support functions are missing from earlier C Libraries.

One final word of caution when passing ZIPs of CLib under the table: make sure you've got the right one. There's a copy in !System.500.Modules (intended to add the above mentioned new functions to 32 bit only RISC OS 5) and another in !System.310.Modules (which adds the new functions and also APCS-32 support).

The penalty of loading a newer C Library is it takes about 100k of RMA.

[wmd]

I can do you two CLib versions: 5.53 (from Marutan's RISC OS 3.71 bundle for RPCEmu) and 5.47 (which I found lurking in my copy of RISC OS 4.39 for VirtualAcorn).

Thanks for upload, however these still cause the same freeze.

[wmd]

@rps102 - here is the !Run file:

Code: Select all

|>!Run
| Run file for !ChuckieEg
|
Set ChuckieEgg$Dir <Obey$Dir>
|RMEnsure SharedCLibrary 5.43 RMLoad System:Modules.CLib
RMEnsure SharedCLibrary 5.43 RMLoad <ChuckieEgg$Dir>.CLib
RMEnsure SharedCLibrary 5.43 Error You need SharedCLibrary 5.43 or later to run Chuckie Egg
RMEnsure BeebSound 1.00 RMLoad <ChuckieEgg$Dir>.BeebSound
WimpSlot -min 228K -max 228K
Run <ChuckieEgg$Dir>.!RunImage %*0

I commented out the line that looks in System.Modules so I could test with the other versions posted in this thread. I tried double clicking on the ChuckieEgg Absolute file (bypassing !Run) but it also does a check for the library and gives the error: "Shared C library is out of date" if you don't manually load CLib. If you first manually load CLib (any of the versions I have) then run the Absolute file,it just causes the machine to freeze.

[SKS1]

If you first manually load CLib (any of the versions I have) then run the Absolute file,it just causes the machine to freeze.

Sounds like you already have a SharedCLibrary loaded in RAM that's in use by some running modules / application. If you load a new one over that, the old modules / applications will still call the old one, probably dying quite quickly in a way that may well just freeze the system.

[sirbod]

these still cause the same freeze.

Try creating a bare-bones !Boot the loads CLib and see if the game still hangs when launched, loading CLib after the Wimp has started is liable to cause hard-locks.

[wmd]

I don't use a boot setup. The default CLib on boot is 3.99 (23 Apr 1992). When I manually load different versions of CLib they give the correct versions when I do *HELP SharedCLibrary.

[wmd]

If you first manually load CLib (any of the versions I have) then run the Absolute file,it just causes the machine to freeze.

Sounds like you already have a SharedCLibrary loaded in RAM that's in use by some running modules / application. If you load a new one over that, the old modules / applications will still call the old one, probably dying quite quickly in a way that may well just freeze the system.

To test for this I searched other games that had CLib in their folders. I found one - Elite. This game loads CLib from its own folder, and the game doesn't crash, so I don't think CLib has to be loaded at boot.

[wmd]

The author of the game (Chuckie Egg) has uploaded the source code if it's of any interest -->

https://mjfoot.netlify.app/riscos.htm

[SKS1]

I don't use a boot setup. The default CLib on boot is 3.99 (23 Apr 1992). When I manually load different versions of CLib they give the correct versions when I do *HELP SharedCLibrary.

Any of the 5.xx SharedClibrary are very likely to need the CallASWI module loaded before them.

[wmd]

Any of the 5.xx SharedClibrary are very likely to need the CallASWI module loaded before them.

Bingo! Game now works perfectly. Thank you!

[gerph]

Ian wrote, regarding warnings raised for loading particular SCL versions:

Why? I'm not sure. Gerph's your man to explain, but IIRC it's down to apps' expectations about how CLib implements things.

SharedCLibrary is dynamically linked to the applications and whilst you can load a replacement CLib once and be ok- because existing things will have linked against the CLib in ROM - loading a 2nd replacement CLib would potentially cause things that were linked against the first replacement to fail because they old module has gone away. Or because the C library private workspace has to remain in the same layout between all versions of the C library otherwise, the library pointer stored in zero page would point to inconsistent details between the versions of the shared library. Whilst keeping the contents similar is expected, retaining the exact same layout of the library workspace is not guaranteed and might have unreliable effects. Until a better solution is found, the SCL remains a potential cause of unreliability for a user's system, especially if they're unaware that loading a modular component might have catastrophic effects on their system (ie reset-inducing). I say 'is found' because this remains a problem.

At the time that the warning was introduced, uptimes were increasing considerably, and expectations of user's usage in multiples of days were reasonable. Together with the expectation of a portable device coming along, with suspend or hibernate functionality, increasing the lifetime of the operating system between resets, it was increasingly likely that people would be installing multiple software components which might cause there to be multiple versions of the SCL loaded, even by individuals who were aware of the possible problems.

That warning in RISC OS Select was probably an unwise thing, but it seemed
sensible at the time, given the problems that were likely to be
caused by people loading different versions of the SCL.

Plus, the versions that were released by CTL had problems with
26bit module callback routines called from SVC mode potentially
corrupting registers

The qsort and bsearch functions, IIRC, weren't correctly handling
the return locations when used in SVC mode. Plus a few of the
routines were plain broken, like atexit. That's what I remember.
There was also something about _Exit too, but I don't remember
what that was.

The warning highlighted the problem to people, whilst in the
background the issues had been communicated to CTL - the warning
was only released in the OS because there had been no response
from CTL to the raised issues.

The warning was reversed after a couple of releases, IIRC, because
it caused such a negative response. We all make mistakes, and that was one I regret.

Together with the backlash against the StubsG library, it was one
of the turning points in realising that there wasn't much future
in RISC OS if there wasn't any interest (or understanding) of the
need for a solid and stable OS, and in supporting systems safely,
from either the users or other developers like CTL. And that
things were far worse than I'd understood.