DDEUtils not 32bit

Just tried to run StrongED and noticed an error “DDEUtils is not 32-bit compatible”.
The DDEUtils module I have is v1.75 and appears to be the latest as I retrieved it from the 5.30 !System download. Is it really not 32-bit?
If I do *help modules it is loaded. Despite the error, StrongED runs.
I’m guessing that this is an error in the way the module is being tested for 32-bit compatibility, rather than it not actually being compatible.

When you say “the 5.30 !System download”, are you referring to HardDisc4, or the “System resources” archive? The latter is not intended for use on RISC OS 5.

A 32-bit DDEUtils can be found in the 5.30 HardDisc4, under !Boot.Resources.!System.310.Modules.

“System resources” archive? The latter is not intended for use on RISC OS 5.

Though that doesn’t sound like the origin since the !System download doesn’t contain DDEUtils, only HardDisc4 and the DDE components files do and both of those have the 32 bit compatible flag set in their module header.

For reference since I looked, only 3 modules appear in both !System and HardDisc4 with differing bitness: Installer, FrontEnd, SharedCLibrary, in the HardDisc4 download they’re in the 500 directory so I don’t think there’s any danger of overwriting a 32 bit only one with a 26 bit only one or vice versa.

Though that doesn’t sound like the origin since the !System download doesn’t contain DDEUtils

I suppose I should have looked before commenting :)

To clarify, I used DDEUtils in the HardDisc4 5.30 download. Its v1.75. Both StrongED and SideDiff complained, saying DDEUtils is not 32-bit. What is happening is SidefDiff does RMEnsure DDEUtils 1.50 and System$Path looks through the modules paths starting at 500 and when it gets to 370 it finds DDEUtils v1.59 and attempts to load it with error.
I upgraded StrongED to 4.70a14 and it no longer loads DDEUtils, so SideDiff is the problem. I fixed it in !Run.
Previously, I missed the DDEUtils in 370 and thought it was trying to load the copy in 310.
Confusingly, !VerMA shows DDEUtils 1.75 32-bit check as “?”. I assumed that meant it wan’t. And StrongED no longer displays the module headers in a readable form, so I wasn’t sure whether it was 32-bit.
As usual, several issues masking the problem. In the HardDisc4 5.30 download, the DDEUtils isn’t in 500, only 310.

so SideDiff is the problem

Without having actually looked at SideDiff I’m going to assume that it’s doing the correct thing, and that the actual problem is your old 370.Modules.DDLUtils file. I imagine if you were to delete it (or at least move it out of !Boot) then the issue would go away.

Confusingly, !VerMA shows DDEUtils 1.75 32-bit check as “?”. I assumed that meant it wan’t.

From memory that arises when the module is compressed and Verma can’t read the info.

Yup, just checked and Verma is confused by the squashing, however the unsqueezed version, from the HD4 download, does show as 32bit (so Sprow is right about the build) but is in 310 directory (so Sprow is wrong about the location)

Maybe it should be in 500 as that is the lowest level at which the module actually must be 32 bit

Without having actually looked at SideDiff I’m going to assume that it’s doing the correct thing, and that the actual problem is your old 370.Modules.DDLUtils file. I imagine if you were to delete it (or at least move it out of !Boot) then the issue would go away.

Indeed.

SidefDiff does RMEnsure DDEUtils 1.50 and System$Path looks through the modules paths starting at 500 and when it gets to 370 it finds DDEUtils v1.59 and attempts to load it with error.

That’s what SideDiff is required to do when finding and loading shared modules. I don’t know how you “fixed it in !Run”, but if you’ve changed the

RMEnsure DDEUtils 1.50 RMLoad System:Modules.DDEUtils

into something else, then you’ve just broken SideDiff…

Maybe it should be in 500 as that is the lowest level at which the module actually must be 32 bit

As supplied, it should probably be in 310 unless it’s 32-bit only; I suspect that the default distribution of !Boot doesn’t have a 26-bit DDEUtils in 370. But if there is a 26-bit-only version higher up the loading order for some reason, then there also needs to be a 32-bit version beyond it (so in 400 or 500) to compensate. When finding a module, the process starts at the highest-numbered version folder and works down towards 310, stopping at the first match it finds.

This is why upgrading !Boot isn’t simple: if you copy across modules from an old system, you risk breaking things in this way. Ideally the upgrader/installer should check for conflicting modules when it merges changes, but I suspect that it would actually need some user intervention. Although, just scanning up from 310 and noticing that

1. There’s a 32-bit module, but
2. It’s not the highest in the pecking order

might be enough to catch a lot of problems.

Although we’ll inevitably have people who then say “But it’s RISC OS – you can’t force me to use an installer.”

Ideally the upgrader/installer should check for conflicting modules when it merges changes

Provided you use the System Merge facility of Configure, this is done automatically; the Installer module (which is doing all the hard work) does a post merge tune up step which removes any modules whose version number is lower than others which exist in lower numbered OS versions. So in this instance it would remove the module from 370 because there’s a newer copy found in 310.

From Installer 0.16 and later it also inspects the 32b flag, because the above scheme would remove a 32b version in favour of a 26b one that existed in a lower numbered OS directory, with predictably comical side effects. The removal now only happens if the lower numbered OS directory copy has the 32b flag set.

Although we’ll inevitably have people who then say “But it’s RISC OS – you can’t force me to use an installer.”

I wonder how many people have standard Boot versus how many have customised FrankenBoots.

(actually, apart from poking in Harinezumi and a bodge for a quirk in NetTime, my setup is pretty standard, it’s just easier that way)

actually, apart from poking in Harinezumi and a bodge for a quirk in NetTime, my setup is pretty standard, it’s just easier that way

I am disappointed to see that compressed modules has come up. These are an even worse idea than compressed executables and just as pointless these days. Many utilities expect to be able to read the module header to determine bitiness flags and what SWIs will be provided.

If anyone is providing compressed modules, please decompress and re-release.

The DDE produces compressed modules, I did not find the option so that this operation does not take place.
I modified the CModule makefile, line ~465 by putting a # in front:

${MODSQZ} ${MODSQZFLAGS} $@

I would prefer a method like for resources:

 

ifeq (${CUSTOMRES},no)