Effects of Changes in Ursula Memory Management on Applications, 
---------------------------------------------------------------
and Testing Strategy 
--------------------

Introduction
------------
An important part of the changes being made to RISC OS to produce RISC OS 4
comprises modifications to the scheme of memory protection and management;
these changes can have unexpected repercussions for user applications, and
may bring bugs to light which have existed unnoticed until this time.

Under RISC OS 3.7 and earlier versions, memory protection was very limited;
broadly speaking, if an application switched the processor into an
appropriate mode, it could read almost all of system space (below &8000) and
most areas above application space (&1C00000 upwards). It could also write to
a number of places outside application space, and outside space occupied by
dynamic areas either owned by it or considered to be shared read/write among
all applications.

Areas which have been Moved, or which are now Protected
-------------------------------------------------------
The few areas of memory which are effectively protected under RISC OS 3.7 are
also protected under RISC OS 4, however a number of additional areas are now
protected such that attempting to write to them (or in some cases even read
from them) from a user process will cause a data abort. According to RISC OS
guidelines a user application should never have need to access these areas
under RISC OS >=3.1 anyway,, however it has been known for applications to do
so inadvertantly.

Note that the address ranges quoted below are supplied to aid debugging of
code initially moved to RISC OS 4. They do not imply that any addresses of OS
areas may be assumed for any version of the OS, nor that any areas are
necessarily public.

The areas which are affected by protection or reorganisation changes are:

* kernel workspace (&0 - &4000)

This area is private and must not be accessed by third parties in any
processor mode. RISC OS 4 protects this area where possible from user mode
writes. Address zero may be protected from user mode reads. The symptom of
broken behaviour is a data abort with a fault address in the range 0 to
&4000; the most likely cause of such a failure is accidental dereferencing of
null pointers. 

* SVC stack (&1C00000 - &1C08000)

This area is reserved for privileged mode. RISC OS 4 now protects this from
any user access. The symptom of broken behaviour is a data abort with a fault
address in the range &1C00000 to &1C08000.

* Environment string returned by OS_GetEnv

This area should always have been assumed to be read only. Under RISC OS 4,
attempting to write to the environment string in user mode will cause a data
abort somewhere in kernel space (qv).

* Copy of physical space (&80000000 - &90000000)

This area is private and must not be accessed by third parties in any
circumstance. On RISC OS 4, there is no longer a copy of physical DRAM space,
and this area of memory has been reassigned for other purposes. The address
range of this area is &80000000 to &90000000; although an application data
abort will not be produced by accessing this area, unperdictable behaviour
will result.

* MMU tables (&2C00000 - &3000000)

This area is private and must not be accessed by third parties in any mode.
This area has moved from its previous location in RISC OS 3.7. The symptom of
broken behaviour is a data abort with a fault address in the range &2C00000
to &3000000.

Testing Strategy
----------------
Checking a huge pile of source by eye to find the call which is provoking a
data abort is not a simple process. A few ways exist to make the job
simpler...

1. Acquire a copy of Dr Smith's Toolkit from Warm Silence
(http://www.wss.co.uk/ ). The memory access checker MemCheck is written such
that any accesses outside areas permitted under application authoring
guidelines will be faulted, so this makes an excellent tool for checking
existing code without having to insert additional routines.

2, etc: to be written.