Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!keith
From: keith@Apple.COM (Keith Rollin)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Application Unexpectedly Quits
Message-ID: <35672@apple.Apple.COM>
Date: 16 Oct 89 02:29:37 GMT
References: <5174@lindy.Stanford.EDU>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 51

In article <5174@lindy.Stanford.EDU> GG.DAR@forsythe.stanford.edu (Aaron Reizes) writes:
>Unexpectedly Quit Problem,
>
>I have an application (MPW C3.0) that allocates most of its
>structures using non-relocatable pointers (NewPtr).  If the user
>opens lots of windows so that there is not much memory left, and
>then selects an option that loads a large code segment, my
>application unexpectedly quits.
>
>The only solution I have found is to leave enough memory for a 32kb
>code segment to load.  I do this by checking MaxBlock each time I
>allocate a new pointer.
>
>Have others found this problem, and what is considered the proper
>procedure to prevent it, or correct it.
>

MacApp goes through great pains to make sure that this never happens to you.
Assuming that you set things up right, it makes sure that your program will
NEVER fail because it could not load in a System or CODE resource.

It does this with a two forked technique. First of all, it determines how much
memory your program will ever need to hold all System and CODE resources at the
time or maximum use. It goes and totes up the sizes of all the CDEF, WDEF, LDEF,
PACK, and MDEF resources, adds to that the sizes of the CODE resources that
you can specify, and then even adds in a little slop for good measure. It then
makes sure that there is always enough memory to hold all of these. It does
this by taking the total size of memory needed, and subtracting the memory
already in use by these resources. Taking the difference, it allocates a holding
buffer.

The second part of the technique takes place in MacApp's GrowZoneProc. This
procedure is responsible for the maintenance of the space holder. If space is
needed for your CODE resource or other System resource listed above, then the
size of the space holder is decreased to allow that resource to be loaded.

This is just the genereal idea of how MacApp handles this problem, and I've
skipped over a lot of the details. It should also be obvious that there is a
lot of work involved in implementing this scheme. However, it is one of the
most robust techniques that I know of, and is one of the better reasons for
using MacApp in developing programs. If you are interested, I could send you
some more information on the technique and implementation. Or, if it is
available to you, look at the file called UMemory.p that comes with MacApp;
the comments there are very complete in describing what is going on.

-- 
------------------------------------------------------------------------------
Keith Rollin  ---  Apple Computer, Inc.  ---  Developer Technical Support
INTERNET: keith@apple.com
    UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith
"Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions