Broken module headers may erroneously report module as not being 32 bit compatible
Rick Murray (539) 13840 posts |
The CheckHeader routine (https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/s/ModHand?rev=4.11.2.13#l2153) reads:
All of the newer tests go to %20, %21, or %88 which reports the not 32 bit error. This does not make sense if, say, the SWI chunk is incorrect. If you set the Init address to be not word aligned, RISC OS reports “Illegal header field in module”. If you set the SWI chunk or flags word to be an odd number, RISC OS reports “Module ‘xxxx’ is not 32-bit compatible” (which may be completely erroneous). Demonstrated: http://www.youtube.com/watch?v=3s0St2vg01w Given that a message for crappy rubbish module headers already exists, would it not be better to use that for cases when the module information is damaged and not necessarily a 26/32 issue? |
Timothy Baldwin (184) 242 posts |
Invalid information is permitted in the SWI fields for the 26-bit modules, which are listed as optional on page 1-210 of the RISC OS 3 Programmer’s Reference Manuals.
Given this, if it has an invalid SWI chunk then it’s probably a 26-bit module without SWIs. |
Steve Pampling (1551) 8170 posts |
Invalid information is permitted in the SWI fields for the 26-bit modules, which are listed as optional on page 1-210 of the RISC OS 3 Programmer’s Reference Manuals. The content of the RO3 PRM’s is of historic interest. Any modules written to conform with the more recent (15 year old?) guide that the fields need to exist, but may contain zeros, is the issue here. I suppose that being accurate all modules written to match the “new” style header model should contain zeros in &18,&1C,&20,&24,&28,&2C while &30 contains zero or &01 depending on 26 or 32 bit status. In terms of the OS, it should check as fully as is reasonably practicable and report an appropriate error. |