ViewXLS

that suggests the correct RMEnsure things for C applications

[…]

is there any compelling reason to update from CLib 5.47?

I had nothing else to do this evening, so… https://heyrick.eu/blog/index.php?diary=20200318

What isn’t mentioned there are that versions prior to, say, 5.70(ish, from memory) have numerous important internal fixes. These won’t make any obvious difference to the application using CLib, but may improve stability.

In that blog post, I’m mostly looking at it from the point of view of “which should I RMEnsure?”.

As to which you should be using… that’s simple. The latest.

5.47 (which is the latest version for VRPC) and try again.

Are you sure about that?

The shared C Library has always been a horrible mess

Let’s just leave it at that. ;-)

since Castle released the Iyonix and tried to stop people distributing it.

Really? From memory, perhaps before things got acrimonious, they were working on an updated CLib that would work on any machine.
Probably something to bear in mind before making accusations is that we have, thanks mostly to Castle’s work, a 26/32 neutral library. We have programs (such as my Manga, for instance) that are perfectly happy on a 32 bit Pi as a 26 bit RiscPC.
We do not have “old 26 bit stuff” and “new 32 bit stuff” with no in betweens, which is what one would expect if Castle really were trying to nobble things against the older machines.

Or, to put it another way, I think you’ll find a standard basic version of VRPC running a standard basic version of RISC OS 4.02 will be quite capable and willing to load and run SharedCLibrary 6.03.

since Castle released the Iyonix and tried to stop people distributing it.

Citation needed. IIRC, distributing the SharedCLibrary was always allowed (and encouraged) for DDE users. This has not changed since the Acorn days.

The shared C Library has always been a horrible mess since Castle released the Iyonix and tried to stop people distributing it.

I think that you could be thinking of the other people, and the attempts to stop a universal version of the SCL from Castle running on a different branch of the OS.

Also, the Iyonix had nothing to do with the “issues” around soft-loading the SCL (the fact that you get one go at it, and then a stiffed machine). It has always been a problem, and will likely always remain so.

Citation needed. IIRC, distributing the SharedCLibrary was always allowed (and encouraged) for DDE users. This has not changed since the Acorn days.

There was a caveat, from Castle, that the SCL should not be distributed. IIRC it prevented a 32 bit or 26/32 bit neutral SCL being distributed that might be able to be used on other 32 bit machines. For the Iyonix it was in rom (and thus no softload would be required).

Are you sure about that?

Pretty sure. It is a Shuttle PC – a RISCCube machine – that I purchased from R-Comp in 2013 with Virtual RISC PC Adjust on it. The last update to VRPC was in January 2009.

There was a caveat, from Castle, that the SCL should not be distributed. IIRC it prevented a 32 bit or 26/32 bit neutral SCL being distributed that might be able to be used on other 32 bit machines. For the Iyonix it was in ROM (and thus no softload would be required).

From memory (and aren’t we all?¹) the do not distribute actually made the specific statement that the copy on the Iyonix linked pages should be used as that was always up to date.
So, not a “don’t distribute” but rather a “don’t RE-distribute” so that everything referenced the same up to date version.

¹ Unless someone has a copy of the old pages with any distribution comments

as that was always up to date.

but was IIRC 26 bit and not suitable for the A9home (or the Iyonix) for example.

but was IIRC 26 bit and not suitable for the A9home (or the Iyonix) for example.

The A9home already has a 32bit CLib in ROM, which in OS4.42 is version 5.59 (ROL numbering). !ViewXLS does startup with that CLib and render my one test piece. Should that ROL CLib be found to not support some later C functionality then the 32bit build of the ROOL CLib 6.03 as found in 500.Modules does softload without immediately exploding, and ViewXLS still work. That is not to say that there are not snags in waiting.

Similarly OS6.20 already has a 32bit aware CLib in ROM and the ROOL 32bit CLib can be softloaded over it, as very superficially tested.

There was a caveat, […]

I see nothing on http://web.archive.org/web/20160309231418/http://www.iyonix.com/32bit/system.shtml that suggests that there is any particular restriction on distributing and using CLib, and this, which I quote in full for you:

RISC OS Select version 1 would not allow the Shared C library to be soft-loaded. The latest version of RISC OS Select known as RISC OS Select 2i3 or RISC OS 4.33 (Kernel 6.24) has now been released by RISC OS Ltd and removes this restriction.

So, you might want to point your finger on the other side of the fence?
Or, better yet, don’t point it at all.

I know what I have said is accurate.

For the sceptical I include below the relevant message in a ReadMe file:

AcornC/C++.EndUser.!System

AcornC/C++.EndUser.ReadMe:

This !System is not to be distributed

Naturally as I had purchased the DDE, I ignored this ridiculous constraint.

I think you are completely missing the point, Chris. If you look at the contents of AcornC/C++, there are TWO !Systems in it. The ‘EndUser’ version can be distributed – see the ReadMe. The ‘Developer’ version may not be distributed because there are additional modules in it specific to the DDE, and not for general distribution (the DDE is still a paid-for product).

And this from a Castle-era DDE:

What’s Here
===

!SysMerge : utility to update system – for public distribution

!System : updated modules – for public distribution

OK, lets summarise:

1. Chris misunderstood the restriction on the Developer version !System and hadn’t realized the bit that was fine for distribution is in the user copy of !System supplied with the DDE.
   Mistakes and misunderstandings happen – next.
2. General users could download 26/32 neutral copies of !system from the Iyonix pages and always be up to date no matter what older version a developer might have included with their product.
3. ROL did produce a restriction in a development version of the ROL OS, then removed it in a later development version and full release.
   Whether this was by accident or design is a moot point best left buried in the pages of history.

People seem to have drifted off the real point:- does the latest SharedC in the !System from the ROOL downloads have all of the functionality required by all software capable of running on all versions of the OS?
If not, why not? If so, why isn’t everyone using it?

The ‘EndUser’ version can be distributed

It is the EndUser version that has this ‘must not be distributed’ message. The message is clear (but nonsense).

The directory makes it clearer – the User directory is empty:

Your interpretation is simply guesswork about what you think would have been a sensible message.

Chris misunderstood the restriction

No. The message is clear but is silly and had to be ignored.

It is the EndUser version that has this ‘must not be distributed’ message.

Which version of DDE is this? I can’t see it.

It is the EndUser version that has this ‘must not be distributed’ message. The message is clear (but nonsense).

Not in my version (the latest, I do not archive previous versions once I am sure there are no problems). Here is an extract from the ReadMe.

Software for distribution to end users
==========

Included with your purchase of the DDE is a royalty-free licence to
redistribute this copy of !System, bundled with your software (commercial or otherwise). It contains the latest version of the Shared C Library, which is necessary to guarantee that your end users can run software compiled with this version of the DDE. This is particularly necessary if the end users are running a version of RISC OS prior to RISC OS 5. This !System can be installed using any version of the SysMerge application.

It cannot be much clearer.

Which version of DDE is this? I can’t see it.

Version 5.56 July 2009. We are talking about the Castle era not the current version.

the User directory is empty

I have no User directory, there is an EndUser directory, and that contains a !System, a ReadMe/txt from which I put an extract above, and a Select_429 directory which contains the patch.

I have no idea why we are not seeing the same thing.

Edit: having seen your post I see we are looking at different versions.

The message is clear (but nonsense).

No, actually, is it not clear given it is a directory called “EndUser”.
The most likely thing is that somebody most likely screwed up and put the information for the developer version into the end user version.

Your interpretation is simply guesswork

So is yours, unless you actually contacted Castle and had them confirm that the 26/32 neutral CLibrary (etc) was indeed not to be distributed.
That’d otherwise be known as “shooting themselves in the foot”, so I rather doubt that was ever the case.

Certainly, there is no evidence of any sort of conspiracy against older machines, ROLtd ¹, or anything non-Iyonix; and plenty of evidence that is was designed as much as possible to be inclusive. That’s why we have a compiler and library that can run the same program in 26 bit worlds and 32 bit worlds.

This !System is not to be distributed; it is intended for developers to
install it in order to add features that are a part of the DDE. See the
file:

  Documents.Manuals.DDE/PDF

for more information.

This is the exact text of Developer.ReadMe/txt in DDE 29a. If the Castle version says the same thing (or something very similar) then I agree with Rick; it looks like someone put it in the wrong place.

I don’t know what every version had, but way back there was a dev !System for the developer, and the then end user !System for distribution. They could have been mixed up…
Around 2004, the dev !System ReadMe said

This !System is not for public distribution.
Use !SysMerge to install !System on your computer.

You can obtain a !System for public distribution from

http://www.iyonix.com/32bit/system.shtml

Naturally as I had purchased the DDE, I ignored this ridiculous constraint.

Not the only time you’ve been confused by software licensing as I recall.

I don’t think there was any confusion. Just a rather unimportant storm in a teacup deciding whether it was the chicken or the egg that came first. A sensible outcome was achieved (some software bundled with the image and other software available via !Store for the user to download) and the wittering died down.

In the case of the DDE it was simpler – Castle had simply cocked up and the only sensible interpretation was the end user should not distribute further. (I quoted the entirety of the ReadMe file.) In later versions the instructions made more sense.

Whether this was by accident or design is a moot point best left buried in the pages of history.

I mentioned “accident or design” in reference to the ROL development that, for a while, blocked the use but the Castle end is clearly accident as the same item was freely distributed from their web site.
Fortunately we can, I think, take heed of the end of my text: “best left buried in the pages of history.”