Showing changes from revision #1 to #2:
Added | Removed | Changed
The Wimp is responsible for managing memory across all system areas. e.g. screen memory, application workspace, system sprites, font cache etc…
Although the system has direct control over all aspects of memory, RISC OS implements an innovative method of allowing the user control of memory if they require. This is achieved via Task Display which is accessible by clicking on the Task Manager icon on the icon bar.
Task Display is an application provided by the Operating System that gives a graphical representation of the system memory resources using bars to display the amount of memory set aside for each part of the system.
The user can re-size the length of a bar to adjust the allocated memory. Reductions in memory of one part of the system can mean an increase in another should the user require it. e.g. Reducing the memory allocated to the RAM disc could mean more memory could be allocated to system sprites. This allows for the user to decide how to make best use of the systems memory at any given time.
Two important bars that can be altered by the user are named ‘Free’ and ‘Next’. Respectively, they provide the size of free available memory available, and the maximum amount of memory that can be used by the next application to be loaded, although this is only used if the application does not explicitly specify how much memory is required by using the *WimpSlot command.
Although RISC OS is a multi-tasking Operating System, it uses the co-operative method rather than the more popular pre-emptive multi-tasking method. Because of this, applications running within the Wimp wrongly assume that they have total control over the system and its memory, and that no other application can be running. As a result, when an application gains control via Wimp_Poll, the Wimp must map the correct pages of physical memory to the applications workspace starting at location &8000 (32,768). This is called its logical memory as opposed to the system physical memory.
Note: The smallest unit of memory mapping that can be achieved is called a ‘Page’ and is usually either 8K or 32K in size.
This memory mapping is carried out invisibly by the Wimp and as a result applications are unaware that it happens.
Applications can (and usually should) specify the amount of memory they need to run without problem. This is achieved by Wimp_SlotSize. This has the same effect as manually adjusting the size of the ‘Next’ bar within Task Display.
Applications should they require more memory for a temporary buffer can request exclusive use of the Wimps’ free pool of memory. Only applications executing in SVC (supervisor) mode can make use of this memory, as it is protected against user-mode access. In addition, while the memory is claimed for use, the Wimp cannot dynamically alter the memory size of other parts of the system. So to reduce any potential problems, applications that request the memory should not claim it for extended periods of time. i.e. across multiple Wimp_Polls.
To claim use of this memory, an application should call Wimp_ClaimFreeMemory.
It is also possible for a user to dynamically adjust an application’s memory allocation by dragging the applications bar within Task Display. However, this is only possible if the application agrees to this when it is first loaded. When an application is loaded, the Wimp issues Message_SetSlot and if the application will allow its memory to be dynamically allocated by the user, should respond. The Wimp will also issue the same message if a user tries to alter the application bar that has already specified it will allow the memory allocated to be changed.
Applications with complex or heavy memory requirements should use Wimp_SlotSize at run time. This allows applications to both take and give back memory to the Wimp.
BASIC programs may use the END=&xxxx
to call Wimp_SlotSize instead.
Applications written in a high level language such as C/C++ should call Wimp_SlotSize directly or use an appropriate call to specify memory requirements.
Applications should never re-configure a machine or kill modules to claim enough memory to load. Such actions are strongly discouraged.