RO 5.20 upgrade for Iyonix

Couldn’t you have just put it in predesk?

So the good news is that you are using clib 5.56 and the bad news is you are using clib 5.56 :-)

Possibly not, that may not be early enough? Actually 5.59, not 5.56 (my C/C++ tools must be newer than yours).

Just make sure that whenever you report a bug to any software developer from now on, you make it clear that you’re running an old version of the Shared C Library. Otherwise you could waste a lot of people’s time…

just make sure that whenever you report a bug to any software developer from now on

Hmmm, isn’t it the case that the author/maintainer of !Writer and !Techwriter has updated at least one of the two and thus the problem doesn’t occur?
Various other apps mentioned have 32-sources, others are in the abandonware category. Patch or ditch.

At present it almost seems some people are asking for long standing bugs to remain.

Steve’s quite right, without the changes he and others can’t develop or port new stuff.

you make it clear that you’re running an old version of the Shared C Library

Actually that is not necessary – if it needed a later one it would RMEnsure it (and either get it or not run).

Actually that is not necessary – if it needed a later one it would RMEnsure it (and either get it or not run).

Wrong. You’re deliberately taking the library back from the default one supplied with the OS, potentially complicating things in the process or adding in new interactions.

If you report a bug in another piece of third-party software, the developer of that is justified in assuming that you have a library no earlier than the one supplied in ROM with the OS that you report that you’re using. This could easily result in them wasting a lot of time looking for bugs that don’t show up on any of the configurations that they try.

the developer of that is justified in assuming that you have a library no earlier than the one supplied in ROM with the OS that you report that you’re using.

But that would only apply to a sloppy and incompetent programmer who had forgotten to RMEnsure the earliest version of the Shared C Library that his programme required. Sloppy and incompetent programmers waste so much more time on other things that this would be a small additional burden that might help them develop. :)

Downgrading Clib is not exactly a viable solution to the Writer+ problem. You could just as well propose that the way to run Writer+ under RISC OS 5.20 is to re-flash RISC OS 5.18. Admittedly, your suggestion is less intrusive by only downgrading part of the system, but it is still a downgrade.

Regarding programs RMEnsuring a later version of CLib: This is a special case since a softloaded CLib cannot be replaced, so any program wanting a later version than the one you softload would fail to start up (provided it uses the correct RMEnsure incantations for CLib). At the moment, it is unlikely that there are any such programs around because the main point of RMEnsures is to make sure that the resident module has all the required features and API entries, and these have not been changed for CLib for quite some time.

I’ve only heard of this being a problem in old easywriter family products maybe you easywriter bods were the only ones clever enough to work out how sscanf works.

Is this the extent of the problem?

a softloaded CLib cannot be replaced

Yes, we’ve managed to achieve that haven’t we? :-)

It need not have been the case.

Is this the extent of the problem?

Yes, it is a trivial fscanf usage error in the EasiWriter family. Fixed in version 8.63 of Easi/TechWriter (in August 2006), but not in Writer+ 1.00, which is much older. Unfortunately, building an updated version of Writer+ is not straightforward. That bug came to light when the fscanf implementation in ROL’s CLib was fixed, which happened a long time before it was fixed in RO5.

Downgrading Clib is not exactly a viable solution to the Writer+ problem.

I’ll agree, certainly not ideal. My ‘solution’ at the moment is to stay with RISC OS 5.16 on my Iyonix and softload 5.20 (with downgraded SCL) when I feel like it. The major issue is that Aemulor Pro 2.32 will not work with 5.20 on the Iyonix. I need to run !Publisher so will stick with 5.16.

Unfortunately, building an updated version of Writer+ is not straightforward.

Patching the jump table after the LibInit call is rather easier.

But that would only apply to a sloppy and incompetent programmer who had forgotten to RMEnsure the earliest version of the Shared C Library that his programme required.

Not really: whether or not a piece of software needs SCL 5.77, if someone reports that it crashes on RISC OS 5.20 then it’s a valid assumption — in the absence of any other info — that they are using 5.77 or better.

We’ve seen stuff like this before with the date fixes: people add them to !Boot, then forget about them. Then the problem being worked around is fixed, but because the bodge is forgotten it stays in situ until things start to go wonky. By which point, the user has forgotten about ever applying the bodge in the first place.

To further what Steve has said – if a person reports that Xyzzy does not work on RISC OS version 12.34 – then the logical (and only logical) assumption is as follows:

• What version of CLib is in that version of RISC OS?

The question arises because *RMEnsure is designed to load a module if the one present is too early; and in the general case this falls in to two categories:

1. As a safety catch for a softload module (like an MP3 player) so if it is not loaded, it will be, and if it is loaded it’ll be left alone.
2. In order to verify that the version available (usually in the OS) is suitable; and if not, to load a later/better one.

For example, pretty much any C program on RISC OS 3.xx as the ones in ROM predate the 26/32 neutral concept so a newer one would be required.

However I would not expect the RMEnsure to fire on a recent version of RISC OS 5(.20 / .21). So if a person told me that a program failed on a recent RISC OS, I would assume in the absence of other information, that the ROM version of CLib was being used.

As Steve said a day ago, slightly reworded for effect:
“Just make sure that whenever you report a bug to any software developer from now on, you make it DAMN clear that you’re deliberately running an old/outdated version of the Shared C Library. Otherwise you will waste a lot of people’s time…”

@Chris Hall: The major issue is that Aemulor Pro 2.32 will not work with 5.20 on the Iyonix. I need to run !Publisher so will stick with 5.16.

Both Eureka and Impression Style now cause my Aemulor Pro 2.32 on Iyonix to error with “File ‘obey2’ not found” and are not loaded, whereas other 26-bit apps seems to load OK. Maybe there is a simple solution…?

Well I have tried the plain vanilla 5.20 HardDisc4 !Boot, with the Apps and Utilities directories renamed (so that they are not seen on start up) on my Iyonix and each time !Style, !Publisher or !Publisher+ are started I get an abort from the same point within Aemulor. With 5.16 all is well. Have you tried !Publisher? Did you use the standard 5.20 !Boot structure? What version of RISC OS are you running (I am softloading 5.20 over 5.16)?

Can you get to the Desktop without running your !Boot program in RO5.16?

If so you could try making a Directory ‘26Bit’ your root harddrive.

Copy in Aemulor – plus some programs that don’t require outside resources.

Copy into your base Directory – !Softload ie RO 5.20.

Run up your machine – without !Boot being run.
Run the !Softload
You might have to type *desktop
When in the Desktop – click on your harddrive icon.
Go into 26Bit and run Aemulor.
Then try your test programs.

I get an abort from the same point within Aemulor

Yes, so do I, with Publisher+ and with Eureka.

Just checking the Aemulor log dump there is the line:

21CD59F0 : .... : 000400F5 STREQD  R0,[R4],-R5        ; ARMv5TE or later

Not sure if that has any relevance at all.

Go into 26Bit and run Aemulor.
Then try your test programs.

Up to this point all OK. 520 is softloaded. But Aemulor requires a boot structure as does Publisher.

So .. after booting into Lang (BASIC) in 520 (after the softload) I RUN 26bit.!BOOT (plain from 520 harddisc4) then Aemulor then !Publisher and I get the abort at 20250DEO-20247C74 = + 916C as before while the Publisher !Run file is being obeyed.

Upgraded my Iyonix from 5.18 to 5.20 via softload. Everything seemed to be working OK until I loaded !Samba v0.08. When I try to shut down, either Shift+Ctrl+F12 or menu option in Switcher it no longer works. Has anybody found this? or offer some advice. Thanks

Regarding Aemulor and Writer+, updating to Aemulor 2.34 – available on the website as a free upgrade for existing users – fixes the compatiblity issue with RISC OS 5.18+. Also note that if you have Aemulor then you can run Writer+ under Aemulor rather than try to downgrade your SharedCLibrary (fraught with problems, and really not the best approach).

Aemulor presents an older version of the SharedCLibrary to the applications that it runs, so Writer+ continues to work. This is an approach that can be useful for sidestepping compatibility issues when the OS is changed, hopefully only until such time as an updated application becomes available. Of course, if you use Writer+ extensively, it’s worth upgrading to Easi/Techwriter instead.

Picking up something from last August…

Name resolution from the Hosts file is now case sensitive. It used not to be.

What are the pros and cons?

I would prefer resolution to be case insensitive. I suspect this may have tripped someone else up too.

I’m not sure if it is defined in an RFC but I’ve always understood that domain names were case insensitive. Even if it isn’t I think we should follow the common practice of being insensitive.