DDEUtils not 32bit
Mike Hobbs (9243) 3 posts |
Just tried to run StrongED and noticed an error “DDEUtils is not 32-bit compatible”. |
Chris Mahoney (1684) 2165 posts |
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. |
Sprow (202) 1158 posts |
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. |
Chris Mahoney (1684) 2165 posts |
I suppose I should have looked before commenting :) |
Mike Hobbs (9243) 3 posts |
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. |
Chris Mahoney (1684) 2165 posts |
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. |
Steve Pampling (1551) 8170 posts |
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 |
Steve Fryatt (216) 2105 posts |
Indeed.
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
into something else, then you’ve just broken SideDiff…
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 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.” |
Sprow (202) 1158 posts |
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. |
Rick Murray (539) 13839 posts |
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) |
Steve Pampling (1551) 8170 posts |
actually, apart from poking in Harinezumi |
David J. Ruck (33) 1635 posts |
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. |
Jean-Michel BRUCK (3009) 359 posts |
The DDE produces compressed modules, I did not find the option so that this operation does not take place.
I would prefer a method like for resources:
|