C_Lib 32bit
Pages: 1 2
Colin Ferris (399) 1809 posts |
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. |
Steve Pampling (1551) 8154 posts |
?? I’m not a programmer (hacking together a few bits of BASIC to multi-launch Popstar doesn’t count1) 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. 1 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. |
Rick Murray (539) 13806 posts |
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:
This should offer ample abilities to roll back / time travel for the purposes of trouble shooting and diagnostics… |
Steve Pampling (1551) 8154 posts |
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
Some postings round here mention using softloaded versions, forcing an early load with the shell method I mentioned.
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. |
Colin Ferris (399) 1809 posts |
Am running RO 5.21 SA RPC (25Jul-13) – C_Lib 5.77 |
Colin (478) 2433 posts |
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. |
Steve Pampling (1551) 8154 posts |
clib 5.70 is the earliest I have. |
Colin Ferris (399) 1809 posts |
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. |
Steve Pampling (1551) 8154 posts |
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. |
Ron Briscoe (400) 78 posts |
I have C_Lib versions 5.54,5.56,5.59,5.66, |
Chris Hall (132) 3554 posts |
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 Tagged as RISC_OSLib-5_76 |
Colin (478) 2433 posts |
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. |
nemo (145) 2529 posts |
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.
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. |
Colin Ferris (399) 1809 posts |
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. |
Colin (478) 2433 posts |
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. |
Colin (478) 2433 posts |
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. |
Chris Hall (132) 3554 posts |
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
and new ones can
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. |
Rick Murray (539) 13806 posts |
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. 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.
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. |
Colin (478) 2433 posts |
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 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.
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). |
Grahame Parish (436) 480 posts |
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. |
Chris Evans (457) 1614 posts |
Graham: |
Chris Hall (132) 3554 posts |
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”. |
Colin (478) 2433 posts |
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. |
nemo (145) 2529 posts |
Good golly. I think it’s this one. 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
There used to be such a thing as backwards compatibility. |
Chris Hall (132) 3554 posts |
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. :-) |
Pages: 1 2