Memory Management
Wimp_SlotSize
Interactive slot resizing
Wimp_ClaimFreeMemory
While the Wimp is running, it maintains a pool of free memory pages, which can become available for programs which need to use the application area. Each task takes a portion of the available application memory (0 if the task is a module!), and the Wimp pages the application memory so that each of the tasks running in application space gets a block of memory starting at &8000 (when it is paged in).
The Wimp's free pool can also be used to give memory to other areas of the machine, if required (eg. if the RMA expands or the screen memory needs to increase), so providing much greater flexibility than was available under Arthur 1.20 (ie. 'No room in RMA' occurs far less often!).
The desktop provides a 'Switcher' icon on the extreme right of the icon bar, which allows a task/memory display window to be opened. This provides a display of the currently running Wimp tasks and how much application memory they are using, as well as an overall memory map showing where the memory in the machine is currently being used.
By dragging either the 'Next' or the 'Free' bar it is possible to tell the Wimp how much memory should be used for the next task running in application space, and how much should be reserved for later. A SWI is provided to alter the amount of memory given to the next application, as well as to alter the amount of memory currently available in application space.
There is also a message-passing system which allows a task to communicate with the switcher so that the user can drag the task's memory slot display to change its slot size.
The following SWI can be used to alter the amount of memory currently available, or the amount to be used by the next task starting up:
Wimp_SlotSize
Entry: R0 = size of current slot (-1 ==> just read setting)
R1 = size of next slot (-1 ==> just read setting)
Exit: R0 = size of current slot
R1 = size of next slot
R2 = size of free pool
The Wimp does not perform the usual MOS actions which are used to
check whether the application space is in use (ie. it does not send
round a Service_Memory to see if the memory is in use, and it doesn't
object if the CAO pointer is inside application space).
On exit the OS_ChangeEnvironment parameters 'MemoryLimit' and
'ApplicationSpaceSize' are updated. Note that the application space
cannot be increased or decreased if ApplicationSpaceSize >
MemoryLimit (eg. if Twin is running above the current application),
since this would confuse the program running above MemoryLimit).
Using this call, it is possible to change the amount of memory to be used by the current task, as long as the current application is able to deal correctly with a change in the amount of memory available to it.
This could happen in one of two ways:
The '*WimpSlot' command allows a *Obey file to specify the minimum and maximum amounts of memory required for an application (it calls Wimp_SlotSize). For further details, see Wimp.Install.
The Switcher utility provides a 'task window' which allows the user to drag various memory slots around in order to alter the allocation of memory within the machine. Those slots which can be dragged are coloured differently from those which are for information only, and they include the Wimp's next and free slots, as well as the font area and so on.
It is also possible for an application to tell the Switcher that it would
like to allow the user to dynamically change the amount of memory allocated
to it. This would be useful if, for example, a program could run with as
much or as little memory as required, using disc cacheing to provide more
memory. In this case the speed of the system would depend on how much memory
was available, so this would have to be a user choice.
Note: the following discussion assumes knowledge of the Wimp's message
passing facilities, detailed in Wimp.Messages. The exact format of the
message blocks is also to be found there.
When the Switcher gets a Message_TaskInitialise (&400C2) message from the Wimp to indicate that a new task has started up, it sends a Message_SetSlot (&400C5) message to the task, with the 'new current slot size' field set to -1. If the task fails to acknowledge the message, the Switcher will change the colour of its task slot to indicate that it cannot be dragged, and will refuse to let the user drag it. If the task wishes to allow its slot to be dragged, it should acknowledge this message, and should respond to further Message_SetSlot messages by acknowledging them and calling Wimp_SlotSize with R0=new slot size, R1=-1.
A call is provided by the Wimp to allow programs such as ADFS to temporarily claim the Wimp's free application memory for operations such as backing-up a disc. The call is similar to OS_ClaimScreenMemory:
Wimp_ClaimFreeMemory
Entry: R0 = 0 for release, 1 for claim
R1 = amount of memory required
Exit: R1 = amount of memory available
R2 = start address of memory
R2 = 0 means that the memory was not claimed (not enough)
NB: Only programs running in SVC mode can access the Wimp's free pool, sinceNote that while the Wimp's free memory is claimed, it cannot give memory up to the RMA, screen, system area or current slot. It is therefore extremely important that the memory is released after use, and it is recommended that the program using the free memory does not call much other code while it has the memory claimed (eg. code which claims blocks in the RMA).