The module was designed to overcome some of the tedious problems faced by ARM assembly langauge/BASIC programmers. The major problem is almost certainly memory management, although the heap manager supplied as part of RISC OS II is useful, it is not infallible, and not always efficient. The main provision of this module, is an improved heap manager that has the following advantages over the current one. It is assumed the reader is familiar with the old heap manager and its terminology
* Moves memory automatically (the old one didn't if you extended a heap block and it didn't fit in it's old position.
* Due to Anchor points (a fixed location pointing to movable heap blocks) facilities for program variable spaces are provided for. Likewise a fixed block can be automatically claim for use as a private USER mode stack which all application must provide.
* The new heap manager can automatically return memory to the wimp. The manager keeps track of extra memory that is claimed for heap blocks from the wimp so that it can (if you want) be returned when the block is released/shrunk.
* The heap manager will (from the size of your code) work out the size of a the heap needed to fill remaining application space - With ONE call, memory for a variable block, stack and the claiming of the heap can be dealt with in one go.
* Fragmentation is impossible. Whenever necessary (ie. when memory is claimed that is not consecutive) the heap is de-framented. This is possible due to Anchor points that are always in the same place (fixed in the variable block.) Compaction of the heap can also be forced prematurely. (to fill in unused processor time). N.B. heap compaction does happen when you resize the heap or a heap.
* The heap manager can automatically clear memory while claims are in progress (heap claim and block claim), this may seem a useless feature, but when debugging software using heaps, it can be annoying and confusing when when the heap contains old data. There are also over obscure circumstances when the entire heap block needs to be zero intialised. Oviously if you do need to do this, use the heap manager routine as it is guarenteed to work!
* Variable wimp slots are extrememly easy to implement. (I had problems when I tried to do it with the old heap manager, it seemed that the application size got 'stuck' at certain sizes, thus meaning that memory was permanently consumed). To deal with slot size changes, you just have to pass a wimp message straight on to the heap manager for processing. The heap manager will resize the heap, and issue the neccesary wimp messages.
* The module can be locked against close down so you can guarentee it won't be deleted until you have finished with it.
The module provides a few other functions:
Memory Move: These are in fact the extremely fast memory move routines used in heap manager. They are highly optimised and can be called direct, avoiding the SWI interface for even faster processing.
Menu Templates: Provides provision for a menu template system that was left out of version 2.00 of the WIMP manager. Unfortunately, Acorn didn;t like the idea of including these into normal template file. Consequently, menu templates use their own file which can be created with !MenuEd, the first program to be written with this heap manager. !MenuEd, at the time writing, is about 60% finished and going well without serious bugs. It will be released soon, probably in a cut down version in the public domain and a full version for about a fiver from me.
I decided to write this module after writing a full desktop program and discovering some of the current heap managers inadequecies. I felt without buying a 'C' compiler and learning to use it the only way to have access to a better heap manager was to write my own. Acorn have given me a SWI chunk number so that side of it is all official and the module can be used without the risk of something else using the SWIs.
The heap manager is not merely provided for die-hard assembly language programmers such as myself, indeed, there is no reason why it cannot be used in BASIC or with other high-level languages.
Of course, it is possible to use this heap manager just like the old Acorn one, Indeed, the SWI interface is very similar, using some of the same reason codes and similar entry/exit parameters but with a considerable number of improvements.
I hope this meets the dreams of all wishful programmers. As this module is expandable, please let me know if there are any ommisions you would like to see implemented in future versions.
Where to put WinSupport?
Well, not such a obvious question as it might seem. Very recently Acorn decreed that they would be giving official approval to well written (complient) software. One of the things that Acorn are trying to sort out is the place that system modules (such as WinSupport)are put. Acorn's idea is to get everybody to the use the !System directory for these instead of application directories. This should avoid duplication, but will result in huge collections of modules (a friend of mine with a 45M hard disc crammed with dubious software has over 50) - fine if you have a hard disc. I would personally agree with Acorn on this matter and suggest you bother using the !System directory.
I haven't yet decided what to do next with the module, If anybody has any good ideas I would be pleased to know. I have, however, decided that is not going to carry window redraw routines, these are legnthy and are best individually written for your program. It is important to keep the size of the module to a minimum or it will become as much of a farce as the shared C library which consume huge amounts of RMA space (over 60K)
Happy programming......(This module is P.D., but please look in the terms and conditions file)
