Showing changes from revision #1 to #2:
Added | Removed | Changed
Entry | |
---|---|
R0 | Bits 0-7: 20 (reason code) |
Bits 8-31: Flags/sub-reason code (reserved, should be zero) | |
R1 | Action: |
0 = Disable compatibility page | |
1 = Enable compatibility page | |
-1 = Read status of compatibility page |
Exit | |
---|---|
R0 | Preserved, or error |
R1 | New status of compatibility page: |
0 = Compatibility page is disabled | |
1 = Compatibility page is enabled | |
-1 = Compatibility page is not supported/required |
This call can be used to examine or control various memory management compatibility settings. Currently the only option that can be controlled relates to the page zero “compatibility page”.
Historically RISC OS has placed the CPU processor vectors and a certain amount of kernel workspace (“zero page”) at logical address &0. This means that applications or modules which accidentally write to null pointers can corrupt the workspace, crashing the system.
In RISC OS 3.8 the zero page workspace was made read-only in user mode. This prevented most buggy applications from crashing the system by writing to zero page, but provides no protection against buggy modules. It also failed to solve the problem of programs malfunctioning after accidentally reading from null pointers.
In RISC OS 5.23 the OS gained the ability to relocate the processor vectors and zero page workspace to &FFFF0000. This provides full protection against null pointer dereferences, but also revealed many bugs in both the operating system and software, most often relating to “harmless” reads from null pointers. On old systems the code would run without there being any obvious indications of problems, but on new systems the code would crash as soon as it attempted the null pointer dereference, most likely preventing the software from being used at all.
To allow this buggy software to continue to function, the option of a “compatibility page” was introduced. This is a single 4K page of memory located at &0 which is read-only in all processor modes, and contains values that are intended to allow “harmless” null pointer dereferences to work OK, similar to if the real zero page workspace/processor vectors had been accessed. If interpreted as a string, the page also contains a message warning the user that a null pointer dereference has occurred.
On systems with high processor vectors / zero page relocation, OS_Memory 20 allows the user or software to enable/disable the compatibility page, as they desire. It’s recommended that software authors disable the compatibility page when testing their software.
On systems with low processor vectors, R1 will be -1 on exit, indicating that the compatibility page is not supported/required (the processor vectors will be occupying the space at &0).
OS_PlatformFeatures 0 and OS_PlatformFeatures 32 can be used to determine the location of the processor vectors. OS_Memory 16 can also be used to determine the size and state of the compatibility page.