MacApp 2.0 Memory Management

MacApp 2.0 Memory Management Any of the following situations can cause an application to stop with a System Error alert, without any chance for that application to gain control: · Not enough memory to load a code segment. Not enough memory to load a PACK resource. Not enough memory to save the bits under a menu which is pulled down. Not enough memory to load a defproc (WDEF, MDEF, CDEF, LDEF). Not enough memory for Standard File to create its file list Add your personal favorite here. Not all commercial Macintosh applications deal correctly with these issues, in large part because doing so involves some rather complicated code. MacApp contains a memory management mechanism which is designed to help keep a MacApp application from getting into these critical memory situations. It does require some work on your part, but makes it much, much easier to produce a robust application than if you did your own memory management from scratch. MacApp's scheme works by dividing available heap space into permanent memory and temporary memory (also known as code reserve). Permanent memory is the space occupied by data which your application allocates: objects and any subsidiary data structures you may create. Temporary memory is reserved for your code segments plus any resources and/or memory needed by the Macintosh Toolbox for a short period of time. MacApp makes sure that your application can't crash for one of the above reasons by always reserving enough space for temporary memory requests to be satisfied. You tell MacApp how much memory needs to be reserved, and it does the rest It only needs to know whether a given memory request is permanent or temporary. Objects created via New (as well as TObjectShallowClone and all other MacApp methods which allocate memory) are automatically taken from permanent memory. You can ask for a new handle from permanent memory by calling NewPermHandle instead of NewHandle; for other kinds of requests you set the "permanent" flag by calling PermAllocation(TRUE). make the request, then set the flag back (PermAllocation returns the previous value of the flag as its result). Any other requests (such as those made by the ROM) default to temporary memory. Note that it is dangerous to have the permanent flag TRUE for any length of time, as any toolbox call which allocates memory or any procedure call which could load a segment will then operate just as it would with no memory management mechanism. For example, calling a procedure in another segment which isn't loaded when the flag is TRUE and there is no permanent memory available will cause a segment loader bomb, even if plenty of temporary memory is available. When debugging is on, MacApp checks for the flag being TRUE in the main event loop or when a segment is loaded and drops into the debugger if it is. If you need to call a routine which allocates both permanent and temporary memory (such as TextEdit, which allocates permanent data structures and which also loads temporary re…