AcornSSL module version?

One of the things that installer does is to install 32bit clib. As such, I guess it needs to exist as a 26bit executable. At least in a world where people seem to refuse to link code with StubsG. Sigh.

One of the things that installer does is to install 32bit clib

Surely you don’t mean “copy a file to disc”. Do you mean “RMLoad”?

Erm, please download the “System” zip on the downloads page on the ROOL website to see what I’m on about. It contains a system zip which is used as the ROOL official “update for older machines”. Worded that way, it is understandable that it is 26bit, but I can’t really understand why in 2019 they’re distributing anything that divisive (ie. it should work on everything).

The only way for a “normal” user to install it is to run the supplied script (a normal !Boot SysMerge isn’t enough). The script makes extensive use of a 26bit Installer module (which it installs in !System.310.Modules) to update !System so that it not only contains the various modules, but also loads 32bit clib in its !Run etc. That’s the official way that 32bit clib gets loaded.

I believe the logic is that a 26bit installer module can be used to install the necessary !System updates to load 32bit clib at !Boot time for legacy systems still running 26bit RISC OS.

What I find annoying is that a universal !System update is helpful for everyone (since there are often times when someone may be a bit out of date on various system modules), and I see no reason to make it 26bit-specific. Surely a well-thought through 26/32 bit !System update would be great for everyone?

Surely a well-thought through 26/32 bit !System update would be great for everyone?

Please don’t.
On a 26 bit system, the OS isn’t able to tell that the module is aimed at 32 bit machines, and it may work but with consequences (remember the original API was all about flag preservation, while the new API is “screw that, it’s hard” – apply that to service call code or whatever and… Things may be unhappy.
On a 32 bit system, short of Aemulor there’s no way to get a 26 bit module to work in a 32 bit world. I don’t mean an agnostic module, I mean 26 bit with TEQPing stuff into PC and all. As such, the OS will rightly refuse to load such a module. I had to spend some time, after copying over stuff from a backup CD, exorcising all the 26 bit modules that made it into System (because stupid here wasn’t paying attention).

There are important fundamental architectural differences between the two types of RISC OS. Mode agnostic modules can help, but not every module is. So it’s arguably better to have a set of upgrades for older machines, and something else for newer ones.
With that in mind, might I suggest… If you’re looking for an up to date !System, would it not suffice to download the harddisc4 archive, then look in !Boot.Resources, and take it from there?

There’s a very strong argument for 32bit versions of Installer using a higher master-version

There’s an even better argument for Installer not being a Muppet. It’s dead easy to tell if this machine is 32 bit or not (three instructions to do it directly, or one SWI call), and it is equally easy to dereference the header to see if the module is 32 bit compatible.
That Installer doesn’t make this obvious check is…pitiable.

Then Installer is broken.

Well, the risible written specification does say… <ducks>

Seriously, though, I agree with nemo. If Installer is going to compare version numbers like RMEnsure, it should compare version numbers like RMEnsure.

[actually, I’m surprised that there’s no API provided to “parse this version number”, it might have been helpful; but then I’m also surprised that the official date format for loads of things is “dd mmm yyyy”, yet there’s no time string conversion call capable of understanding that format]

At least in a world where people seem to refuse to link code with StubsG. Sigh.

How does that work for those of us using GCC or GCCSDK to compile our software?

Not a clue, Steve – never used GCC in anger. But also completely irrelevant since Installer isn’t compiled with GCC.

I don’t get why people get so riled up about StubsG, except for a 20+ year old political thing (which is now past history for the companies involved). Justin created something that allows software to run on both OSs without the user needing to install a different Clib module. Is that really so horrible?

I believe that GCC stuff (mostly ports) tends to link to UnixLib rather than SharedCLibrary, although I believe it’s a user choice. I may be wrong, but using SharedCLibrary would probably mean not using many of the newer GCC nicities such as !SharedLibs/ELF.

Rick – valid points, but 26bit modules may need to exist for use by Aemulor-using apps. Can’t just pretend like they don’t exist. Well, not as responsible platform holders looking out for all RISC OS users :)

(Translation – am just having some problems literally right now with 32bit-safe modules causing problems for some important legacy apps).

Secondly, I think we need to move forwards from a “download the whole disc image and dig through it for module updates” approach. It’s valid, yes, but not exactly user friendly. And we need to work on improving that. I don’t have all the answers, but if we’re going to make headway with RISC OS, we need to be making things easier.

Background, I spend my days oscillating between building 32bit RISC OS 5 systems and trying to support users with Iyonix or earlier systems with mismatched xyz wanting to run current software. Today I’ve had to assist two VirtualAcorn setups with a hodgepodge of versions of things (why won’t Netsurf, Fireworkz, Artworks etc work?), an Iyonix and some ARMbook queries. I see all sorts of users and most of them seem to be in some degree of mess. Anything that can be done to simplify and unify their problems/solutions can only be a good thing.

I believe that GCC stuff (mostly ports) tends to link to UnixLib rather than SharedCLibrary, although I believe it’s a user choice. I may be wrong, but using SharedCLibrary would probably mean not using many of the newer GCC nicities such as !SharedLibs/ELF.

NetSurf aside, I’ve never built anything “production” with GCC which didn’t use the SharedCLibrary. That’s all of my C software: CashBook, PrintPDF, Locate 2, Launcher, PS2Paper, and probably a few other things. I don’t need the ELF stuff; I just need a compiler that plays nicely with modern development tools such as version control (let’s not mention the RISC OS SVN port, shall we?).

Since I got IcnClipBrd building in AsAsm, I don’t actually use the DDE for anything development-wise.

I don’t get why people get so riled up about StubsG, except for a 20+ year old political thing.

Didn’t Druck raise some technical issues at the time, which sounded fairly serious and culminated with “I wouldn’t use it”? ROL never responded, as I recall.

ETA: Oh, and where does StubsG stand with C99 support? I’m afraid I’m not going to be removing bounded printfs from my code any time soon, if you don’t mind.

But also completely irrelevant since Installer isn’t compiled with GCC.

With respect, I was responding to “At least in a world where people seem to refuse to link code with StubsG. Sigh.” – which didn’t mention Installer.

Secondly, I think we need to move forwards from a “download the whole disc image and dig through it for module updates” approach. It’s valid, yes, but not exactly user friendly. And we need to work on improving that. I don’t have all the answers, but if we’re going to make headway with RISC OS, we need to be making things easier.

If we were to put each “component” (which in some cases may be more than one module, eg. URL + AcornHTTP) into a PackMan package, then interested parties could let PackMan auto-update everything. In the case of packaged apps, they can have dependencies on the minimum component versions that they require, once again handling everything automatically.

There are probably some downsides to this (one that comes to mind is that PackMan gets confused if people go “behind its back” and move/update files that it thinks it’s managing), but it seems like a starting point…

At least in a world where people seem to refuse to link code with StubsG

Sadly, StubsG is getting a bit out of date. E.g. it doesn’t support 64 bit number (uint64_t) maths operations. I’ve had to revert to standard stubs for Doom for that reason.

I can’t really understand why in 2019 they’re distributing anything that divisive (ie. it should work on everything).

Absolutely. Although, at some point last year I re-built my RISC PC (Kinetic) to try and remove a corrupt cursor. I tracked the problem down to RISC OS 4.39 and so I reverted to an earlier version of Select.

However, during my attempts at resolving the issue, I archived !Boot and downloaded a fresh copy from this website. It was okay for some apps, but others ran with strange errors. Which made me wonder… Did the developers use different developement tools – !DataPower, !Techwriter.

As the downloaded system files broke !TechWriter’s menus I refreshed !Boot from Select.

;-) The moral of this story – beware of downloads from this website that claim to work on legacy systems… I can only guess that my experience was a result of historical differences between two companies.

I have both a RISC PC and a RPi, so I like the idea of !PackMan being able to update both systems.

Sadly, StubsG is getting a bit out of date. E.g. it doesn’t support 64 bit number (uint64_t) maths operations. I’ve had to revert to standard stubs for Doom for that reason.

I use some 64-bit integers in some of my modules and have no problem linking them against StubG 0.04. As far as I can tell it goes to the inclusion of _assert2(). So I think it basically misses the the functions about complex math and the 64-bit file handling.

However, during my attempts at resolving the issue, I archived !Boot and downloaded a fresh copy from this website. It was okay for some apps, but others ran with strange errors. Which made me wonder… Did the developers use different development tools – !DataPower, !Techwriter.

My first thought there is !Toolbox, I’ve had experience of issues with certain RSSC software which were resolved when the software was rebuilt using a non-ROL version.

The moral of this story – beware of downloads from this website that claim to work on legacy systems…

Of course the general advice regarding that is that Toolbox based apps may require the other side’s toolbox. This has always been the case and even before RO5.x people using a RiscPC could discover problems with certain applications, sometimes only small features related to a specific Toolbox gadget, sometimes more extreme.

The real moral of the story is to test thoroughly and check what alternate features are used by an application.
Temporarily kill the existing Select version of Toolbox and run the ROOL version – if the errors are rather familiar to you then you just identified an application that expects the ROL Toolbox.

I can only guess that my experience was a result of historical differences between two companies.

In the case of Toolbox you’re right because what ROOL have the right to distribute doesn’t include the ROL Toolbox. A quick fix might be for 3QD to pass over the source for their version of Toolbox and allow development of a version suitable for all systems.

StubsG, mentioned earlier, would be a similar thing where some development work is clearly needed, as per Mr. Doggett’s comments about certain features not being supported.

In both cases there’s some discussion to be had, possibly Andrew can speak on friendly terms and arrange something, but I don’t think anyone should expect a rapid resolution.
I’m sure there’s a bounty relating to the Toolbox issue.

I use some 64-bit integers in some of my modules and have no problem linking them against StubG 0.04.

I found they worked until I needed to multiply or divide. _ll_mulss, _ll_sdiv, _ll_srdv, _ll_udiv amongst others are not supported.

In the case of Toolbox you’re right because what ROOL have the right to distribute doesn’t include the ROL Toolbox. A quick fix might be for 3QD to pass over the source for their version of Toolbox and allow development of a version suitable for all systems.

In case you’re not aware, there’s a bounty for consolidating the Toolbox. I think starting with ROL’s source is probably the best approach (if we can get it!) as there haven’t been too many changes to the ROOL Toolbox over the years, so it’s probably easiest to start with ROL’s and reapply any ROOL-unique changes.

In case you’re not aware, there’s a bounty for consolidating the Toolbox.

I assume you got bored before reading the last line of my post :)
“I’m sure there’s a bounty relating to the Toolbox issue.”

Andrew Rawnsley said:
bq.I think we need to move forwards from a “download the whole disc image and dig through it for module updates” approach

I always thought that it’s fine for geeks who want to download and test whatever has been checked-in to GitLab. Everyone else is welcome to buy the latest ‘point-and-click and auto-update to long-term tested build’ machines from the likes of yourself. Maybe there is a middle ground, and I am oversimplifying?

How about the ROOL disc image being split up into packages and managed with PackMan? Not sure exactly on the best way to divide up the disc image: what exactly should define a package? Is Boot a package, for example? If we can get PackMan (or a utility to download PackMan) built into the ROM image, then couldn’t everything update auto-magically?

Of course, even with such wizardry, you may struggle to transition anyone from their current setups: there are so many different starting points! And this platform has a historical reluctance against the use of packages.

I considered myself an advanced user back in the day, but when I dabble with RISC OS these days, I frankly cannot be bothered to dive about and manually update things. It’s just too painful. And I know the process. I can’t imagine how a less-experienced or (shock, horror!) new user might cope.

I found they worked until I needed to multiply or divide. _ll_mulss, _ll_sdiv, _ll_srdv, _ll_udiv amongst others are not supported.

I have them here but also found a file named StubG004 which doesn’t contain them. So 0.04 may not have been the latest version like I thought.

Now that I think of it, I may have received a test version directly from the developer after reporting an issue. Considering the file size difference 95KB versus 16KB, it must indeed contain a lot of additional functions compared to the latest official release.

I assume you got bored before reading the last line of my post :)

That’s what I get for posting before 7 AM… :P

There was some confusion about module version number formats, which revealed some problems with the documentation of Modules on this site: Only half of it was there, and wasn’t all correct.

I’ve given the Relocatable Modules page an overhaul. I’ve left much of the chatty introduction, but added a lot of detail and missing information. Not least the SWI Decoder, which is little known.

I could do more (I haven’t explained syntax string bugs in various OSes) but it’s late, and there’s already plenty for people to argue about. Have at it.