index   prev   next RISC OS Notes

CLIB SharedCLibrary

The distinction 32-bit vs. 26/32-bit has never been relevant. For all released RISC OS software I have seen 32-bit-compatible always means 26/32-bit-compatible. The problem is that the term "32-bit" has been used with a different meaning for CLib specifically, so that is causing the confusion. For everything except CLib, "32-bit" always means "32-bit-compatible", i.e., "works correctly on RISC OS operating in 32-bit mode", i.e., RISC OS 5 on various systems (e.g., Iyonix), plus RISC OS 4.42 on the a9home. For CLib, the first use of "32-bit" meant "supports APCS-32", a new mode of operation required by 32-bit-compatible C programs. That is completely independent of the fact whether the CLib module itself is 32-bit-compatible in the above sense or not. CLib 5.56 demonstrates this: It supports APCS-32, so it is what is commonly called a "32-bit CLib", but it is marked as a 26-bit module, so it is NOT 32-bit-compatible. RMEnsure SharedCLibrary 5.17 RMLoad System:Modules.CLib

# patch for risc pc

The Offical 32bit release of the Shared C Library and Toolbox modules can be downloaded from http://www.iyonix.com/32bit/system.shtml If you are running a version of Select that prevents the loading of the new SharedClibrary, you are urged to upgrade to Select 2 which removes this restriction. However this patch will allow the Shared C Library to be loaded on any version of RISC OS. This program must only be used under the following conditions:- You acknowldege that both this program and the 32bit Shared C Library are totally unsupported 3rd party components. You hereby and forthwith agree not to raise any Select support issues to RISC OS Ltd before checking that the problem is also apparent with the ROM based C Library. To use place the SharedCLibrary !!!LoadSCL in !Boot.Choices.Users...Boot.Predesk I am certain that it works provided that: * CLib is only ever loaded from System:Modules * CLib 5.43 has been installed to !System.310.Modules * you have RISC OS 3.1 or higher * applications use the correct RMEnsure sequence If you can find a way to make things go wrong while none of these conditions is violated, please let us know. So, to sum it up, from the way it was designed and from experience I claim that each of the following FIVE cases work: A Put the new CLib in !System.310.Modules and the various copies of FPEm in their respective directories as in the official distribution and do not change anything else in !System - applications needing the CLib will request it. This is the minimal installation. THIS ASSUMES that all applications use the correct RMEnsure sequence. B Put the new CLib in !System.310.Modules and the various copies of FPEm in their respective directories as in the official distribution and add appropriate RMEnsure lines to some place in your Boot sequence where it is executed, e.g., in PreDesk. You need to use the correct RMEnsure sequence. This is slightly more safe than A because even applications with the INCORRECT RMEnsure sequence in their !Run files will work (fortunately, I have not seen one so far). C Allow the RO4 SysMerge to update your !System (by double-clicking on !Boot and using System Merge) instead of using the SysMerge script supplied with the new !System. According to Lenny, this fails to update !System.!Boot and !Run, but this does not matter. See case A. D Allow the supplied SysMerge script to install the modules and update !System.!Boot and !System.!Run - then, the modules will be loaded automatically at start-up. Same effect as case B. E Running the Select installer after using the SysMerge script, according to Druck, downgrades !System.!Boot and !System.!Run, but this does not matter. See case C (and subsequently, A). So, whatever you do: As long as the modules are in the correct place in !System, the RMEnsures added to !System, if present, are correct and applications use the correct RMEnsure sequence, then everything is fine. Martin W. In article <52bd999662cvjazz@waitrose.com>, Chris Newman wrote: > IDEFS::h-4.$.!Boot.Resources.!System.Modules. This directory is redundant and should normally be empty, unless you are running *very* old legacy software which looks only there. 310.Modules is the place to put modules, unless there are versions for specific version of OS, and then they would go into 400.Modules, 500.Modules etc as appropriate. -- Chris Johnson If you do (in a task window - Ctrl-F12) *show sys* (the trailing * is a wildcard) you should find an entry for System$Path which will look something like (depends on OS version) System$Path : Sys:500.,Sys:400.,Sys:370.,Sys:350.,Sys:310.,ADFS::Dorset1.$.!Boot.Resources.!System. This is the order the OS looks for modules when loading them from system. It starts at the highest OS version, so that if the later OS needs a different version module than older OSs, it is loaded in preference. It works through the list of module directories until the module is found. The final entry, which is the !System.Modules dir, is looked at as a last resort. The default place for modules suitable for all flavours of OS should be 310.Modules. Thus you could, in principle, have the 'same' module, although different versions, in every one of these NNN.Modules directories. In this case, when a !Run file is executed with a command such as RMEnsure SomeModule 9.99 RMLoad System:Modules.SomeMod on RISC OS 5, the module in 500.Modules would be loaded, whereas on RISC OS 4 the module in 400.Modules would be loaded and so on. The OS will never look in a directory higher than itself even if the directory happened to be present on the machine. HTH -- Chris Johnson

© JR 2013