C_Lib 32bit

Is there a 32bit version of the SharedCLib available?

What is the main difference between the ROM versions and the soft loadables?

It would be handy to have back versions available – so you could backtrack – to find out what changes – have upset older programs – that don’t have their sources available -ie they are now very large asembler progs.

Is there a 32bit version of the SharedCLib available?

?? I’m not a programmer (hacking together a few bits of BASIC to multi-launch Popstar doesn’t count¹) but isn’t the module at position 12 in the output of *mod. 32-bit? It’s in RO5.21 and I was sort of assuming all the ROM modules were 32-bit.

Back versions: would that be as simple as extracting the module from ROM with a tool like Verma and then wrapping it in a multi !!!! labelled shell folder?

I suppose softloading different revisions from 5.18 up on a machine with a minimal boot would do for the extract.

¹ I needed quick ability to change ISP, user and password. Sorts outgoing mail into different user based directories and changes the Popstar mail directory along with the user/password etc.
The codes rough, I should be ashamed, but it works.

I suspect that he might mean “for older hardware”? Ignoring ROLtd’s versions, RISC OS has been 32 bit for a long time!

Would extracting a ROM version to softload work? Doesn’t the ROM version have specific addresses baked in? Or was that only back in Acorn’s day?

I’d agree that we ought to maintain some older versions here; maybe not of CLib but possibly of the ROM builds.

I would suggest:

• Yesterday
• Day before yesterday
• Last Monday
• Last Monday before that
• Important milestone builds

This should offer ample abilities to roll back / time travel for the purposes of trouble shooting and diagnostics…

I suspect that he might mean “for older hardware”? Ignoring ROLtd’s versions, RISC OS has been 32 bit for a long time!

For older hardware – presuming you mean older than RPC/A7000 which has 5.20 available – the answer would be the Castle offering at http://www.iyonix.com/32bit/system.shtml

Would extracting a ROM version to softload work?

Some postings round here mention using softloaded versions, forcing an early load with the shell method I mentioned.

I would suggest:
Yesterday
Day before yesterday
Last Monday
Last Monday before that
Important milestone builds

I’d say IF that kind of thing is done weekly and monthly plus milestone would probably be easier in that the milestone versions seem to be on the list already (stable) and weekly/monthly covers everything other than the minor versions that interested users will probably keep themselves.

Am running RO 5.21 SA RPC (25Jul-13) – C_Lib 5.77
Want to backtrack the C_Libs – so I can find out which changes have upset older programs.
Softloading C_Lib 5.75 loads ok – but when C Progs are run – I get the error ‘Unknown library chunk’

If you load it while a C program is running it doesn’t work even if it looks as though it loads ok. That’s why it needs to be loaded first in !boot.

Softloading C_Lib 5.7 loads ok

clib 5.70 is the earliest I have.

Should be able to replace the C_Lib once – but did try in PreDesk – first in line – same error given – !boot is stopped.

Jus run C_Lib 5.53 (19 Dec 2006) Graham Shaw’s Open version – in desktop – Loaded OvnPro ok-afterwards.

Jus run C_Lib 5.53 (19 Dec 2006) Graham Shaw’s Open version – in desktop – Loaded OvnPro ok-afterwards.

erk, version clash! The Castle issued 5.53 (14 Mar 2005) is the one on the Iyonix web pages.

I’ve found a copy of 5.55 (2009-07-19) in the general files.

I have C_Lib versions 5.54,5.56,5.59,5.66,
5.72 and 5.77 here if it helps.

This is a minefield. Castle’s 32bit shared C library is copyright and can’t be distributed (IIRC) and what it offered as something to distribute was actually 26bit (IIRC). This was a real nightmare with the A9home. However this module is now in ROM so the issue goes away (except for the unwise bug fix that has broken older software).

Want to backtrack the C_Libs – so I can find out which changes have upset older programs.

I think it’s this one.

Fix to scanf of a scanlist where no match occurs
In this situation, the conversion should fail.
Fixes ticket #252.

Tagged as RISC_OSLib-5_76

Despite not being happy about my copy of techwriter not working with the new clib I think it is right to fix the bug.

The only solution I can see at the moment is hacking an old CLib so that it has a new swi chunk/name then hacking the program to change the CLib SWI numbers in it. Then the old program will use the legacy clib. Only works if there is no copy protection.

It would be handy to have back versions available – so you could backtrack

I’ve often thought so. Windows’ System Restore has occasionally got me out of trouble, but there’s no equivalent for RO.

It would be easy enough in principle to arrange for backup copies of modules to be made when they are overwritten by a newer one – such a “Module Restore” module could be retrofitted on any version of RO.

This is a minefield. Castle’s 32bit shared C library is copyright and can’t be distributed

If copies were made locally this wouldn’t be an issue. Not being able to run an old program you’ve just downloaded because it requires older modules is a different (and much less serious) problem than not being able to run your existing programs because something else upgraded a module. The latter ought to be guarded against.

Would have been useful for newer programs that are being updated – to have added a flag in the call to the C_Lib – so they could use the updated version.
Leaving older programs to run as before.
Otherwise the number of ‘C’ progs that you can run ok – will quickly drop off.
Unless you run two ‘C_Libs’ one old and one updated – getting the newer ‘C’ program to call say – C_Lib2.

Fixing bugs in the C library shouldn’t cause problems if they are written properly – they may even fix eratic bugs in programs. The changes only make clib conform to the standard, they are not adding anything new and it is essential that the functions conform to the standard to be able to use code from other compilers.

The problem with 2 libraries is that I can’t get CLib bugs removed without buying a new compiler.

I think a LegacyClib with a different swi chunk together with a program to patch !Runimages is probably the best way forward.

What about the situation where 1 program fails with CLib xyz but another program works better.

Just to let anyone interested know the scheme I outlined using a LegacyCLib does work. I changed a copy of SharedCLib 5.53 to give it a new SWI chunk and rename it LegacyClib. Then converted the SharedCLib SWI’s in techwriter to LegacyCLib SWI’s (there are only 2 – should be only 2 in all programs) So now my version of techwriter works with versions of riscos running the bug fixed SharedCLib.

I was hoping that you would be making a version of Shared C Library that was up to date, except for the bug fix, that could be softloaded in place of the ROM version. However you seem to have tweaked the 5.53 version.

Why not just softload the 5.53 version and unplug the rom version?

I think that the best solution is to remove the bug fix, create a version of the Shared C Library witout the bug fix. Then rename the shared C Library, add the bug fix and as more features are added programmes can RMEnsure a library with a different name, rather than specify just the version number.

Existing programme can then

RMEnsure SharedCLibrary 5.17 RMLoad System:Modules.clib

and new ones can

RMEnsure SharedCLib 5.60 RMLoad System:Modules.clib2

That would suit all? Not many programmes seem to require the shared C library now – most !Run files indicate that it isn’t used. Presumably two C libraries can happlily co-exist, as programmes using them get a vector (I assume) so that they point to the right one.

Then rename the shared C Library, add the bug fix and as more features are added programmes can RMEnsure a library with a different name, rather than specify just the version number.

I think this depends upon what the bug fix actually is. Because on the face of it, a flaw in CLib has been corrected and any program that used, relied upon, or otherwise depends upon characteristics of behaviour that does not match the documentation is, in effect, itself buggy.
Now this may create complications with older software that does not stand a hope of being fixed; and a workable solution is for those programs to be modified to use a clone version of an older CLib – it is not hard to whip through a piece of code replacing SWI numbers on the fly; this behaviour could perhaps even be added to AppPatcher?

However, never should a current or future version of CLib carry a different name unless changes made cause it to be fundamentally incompatible with existing software. The correction of bugs is not an incompatibility.

Not many programmes seem to require the shared C library now –most !Run files indicate that it isn’t used.

Eeehhhh? You do realise, I hope, that RMEnsure is intended to verify that a specific minimum version is present? Regardless of whether or not the RMEnsure line appears to do anything, I think it is safe to assume that any program with that line will require some version of CLib.
Pretty much any program or module written in C, which is a quite possibly the majority of them, will require CLib (or UnixLib?).

I don’t think its a good idea to have 2 versions of a module with the same verson number and undoing the fix would be tricky – I don’t have the source code.

I was hoping that you would be making a version of Shared C Library that was up to date, except for the bug fix

I altered 5.53 because that is the version I had from an old C/C++ and it was newer than Techwriter needed.

We agree that the only solution is to have 2 SharedClibraries.

Not many programmes seem to require the shared C library now.

That is not an argument for your solution. If few programs need clib and even fewer programs are affected adversely by the fix then it isn’t a great problem.

Not changing SharedCLibrary and introducing NewSharedCLibrary for new compilers means that people have to buy the new compiler.

There would be no need for the old version to be in a separate module it could be implemented as a different entry point to the clib module (which would give you a different function table).

Surely, Techwriter is a currently maintained program that should be fixed rather than ‘unfixing’ CLib. What needs to be determined is which unmaintained programs are affected by the CLib bug fix and look for a way of patching/fixing/using an alternate program/etc. It just sounds totally wrong to me to undo a valid fix for the sake of broken software.

Graham:
True but not everyone can afford or justify the expense of upgrading maintained programs and what of unmaintained programs?
Most people have to be pragmatic.

I did ask ROOL not to include that particular bugfix in 5.20 before it was published. So all I can say now is “I told you so”.

I can’t see that ROOL would be worried about it. Yes it would have been preferable that it didn’t happen but it isn’t a bug in RISC OS its a bug in the program that fails – later Techwriter versions for example have fixed it. As there is no invisible fix delaying it would have solved nothing.

Good golly.

I think it’s this one.

Fix to scanf of a scanlist where no match occurs
In this situation, the conversion should fail.
Fixes ticket #252.

That’s only one call, so it’s a bit overkill to load two copies of the whole library. It is only the scanf call that needs to be changed in certain cases.

One could envisage a simple star command to select the old version of scanf on the next SharedCLibrary_LibInit* call. Add that to the !Run of any offending application and hey presto.

I can’t see that ROOL would be worried about it.

There used to be such a thing as backwards compatibility.

That’s only one call, so it’s a bit overkill to load two copies of the whole library. I

With my limited knowledge of C, I was only identifying a solution that would work, not one that would be elegant. I have found in my (much more extensive) experience within IT that you only get the IT specialists to concede something is possible if you identify a solution that would work but which, for some reason, is anathema to them. :-)