Service_ModulePreInit

Service_ModulePreInit was added in RO3.7 to allow SA incompatible modules to be patched, however in RO5 the 32bit compliance check is done before the service call is raised, so its never called.

Shouldn’t Service_ModulePreInit be raised first and a 26bit module rejected if the call wasn’t claimed or an error returned? Admittedly the behaviour of this service in RO5 doesn’t lend itself to patching, as there’s no way to notify if any patching has taken place. In the RO6 documentation it states the service should return an error if the module is to be rejected. Based on this, perhaps the behaviour should be changed to match RO6 and the 32bit compliance check should hang off this service call, instead of being in ModHand.

In its current state, this service call is pretty much redundant on RO5 – which is a shame, as it’s an ideal solution to patching 26bit modules to be 32bit compliant.

There’s a StrongARM condition around the Service_ModulePreInit in ModHand (line 2087), does that mean it’s not in the Pi build?

Looking at what changes would be required, the No26bitCode sections at lines 2169 thru 2189 and 2206 thru 2224 in CheckHeader would need moving to code that responds to Service_ModulePreInit and code needs inserting after the service call at line 2096 to check if service was claimed and module rejected (R1=R2=0) if so, exit with the error returned.

There’s a StrongARM condition around the Service_ModulePreInit [code], does that mean it’s not in the Pi build?

No, the StrongARM switch is always on. I generally read that switch as “support for split I+D caches”.

In its current state, this service call is pretty much redundant on RO5 – which is a shame, as it’s an ideal solution to patching 26bit modules to be 32bit compliant.

It’s only redundant for the trying-to-run-26-bit-modules-on-32-bit-os case, and that’s a configuration specifically ruled out as it’s an in between state.
I’m not sure of how general you’re trying to make the JASPP work, because trying to hook onto Service_ModulePreInit wont do anything on RISC OS 3.50 & 3.60 if for example you want to patch a 3.10 era game to work on a Risc PC era machine.

The extension in RO6 to return an error is especially vile, since R1=0 claims the service call, but what’s to say something later in the service call chain doesn’t know how to patch the module successfully?

My suggestion would probably to watch for OS_File (via FileV) loading a thing of type module into the RMA dynamic area address range. As an aside – I’m sure you’re aware that 26 bit code sequences aren’t the only thing to replace, stuff like calling non 32 bit safe APIs (eg. OS_HeapSort) will likely need attention too, though this probably overlaps into what Aemulor does quite a bit.

The point I was making is that the behaviour of Service_ModulePreInit has changed on a 32bit OS. On 26bit its function is to allow non-SA compatible modules to be patched. On a 32bit OS that’s no longer it’s function, it’s now for general patching of 32bit compatible modules.

Do 32bit compatible modules need to be patched?

as it’s an ideal solution to patching 26bit modules to be 32bit compliant.

Please make this turn-offable. Modules can do all sorts of exciting things (fiddle with the IOC, anything that uses Timers will likely fall into this category); there are a myriad of possibilities that would need to be considered, and RISC OS isn’t so forgiving of quirks in module level code. An application crash is usually recoverable. A module crash, less so.