Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Moving resources into the system file
Message-ID: <8102@hoptoad.uucp>
Date: 23 Jul 89 01:03:33 GMT
References: <1230@uvm-gen.UUCP> <8065@hoptoad.uucp> <12810@well.UUCP>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Distribution: na
Organization: Eclectic Software, San Francisco
Lines: 68

In article <8065@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes:
> ExitToShell *should* be releasing application-heap copies of the system
> file resources under MultiFinder.  I know it does under UniFinder.
> However, if you think about it, there must be some sort of weird
> special casing involved.  There's a dearth of internal information on
> MultiFinder, but a little poking with MacsBug reveals that different
> applications each have their own copy of the system resource map.

In article <12810@well.UUCP> brecher@well.UUCP (Steve Brecher) writes:
>Application heap handles are removed from the System map by RsrcZoneInit,
>which is called during the launch process under uniFinder but not called
>under MultiFinder.

That's correct, but there must be some analogous call which is made
under MultiFinder.  Otherwise, copies of resources in the system map
that appeared in the application heap of one application would be
trashed when the next application ran.  (Good guess, but false --
see below.)

>There is only one copy of the System map.  Each layer has its own resource
>map chain (TopMapHndl is switched), but each chain links to the System map
>in the system heap.

You're right, I was wrong.  I was looking at SysMap and thinking it was
the handle; in fact, SysMapHndl is the handle.  The illusory four-byte
SysMap changed every time because the second word is actually another
low-memory global, which is switched.  Sigh.

>[Tim's diagnosis (not quoted) of the original problem was correct, i.e.,
>adding application heap handles to the System map under MultiFinder and
>then quitting without releasing the resources leaves dangling handles in
>the System map.]

Yes.  I'm just wondering why there's a difference between adding
resources to the map and just accessing them.  They must be thrown away
somehow if they're in the application heap; when the system decides to
throw them away, what's the difference between one that's been added
recently and one that hasn't?

The only way I can see that they would *not* have to be thrown away
would be if they were not ordinarily read into the application heap.
I've just done a bit more probing with MacsBug, using the HD command,
and I can't find any resources in any application heaps that claim to
be from resource file 2, which is the reference number of the system
file.  In fact, when I check DA Handler with a DA open, whose resources
you would think would be in the DA Handler application heap, there are
no resources except from the DA Handler resource file.

So perhaps under MultiFinder all resources in the system file are read
into the system heap whether they have the system heap bit set or not.

I just looked at the system heap with MacsBug and there are indeed a
number of resources there from file 2 which, when examined by ResEdit,
do not have the system heap bit set.  So that would appear to be the
answer.

So, the original questioner could do a ReleaseResource as I suggested,
but a better approach would be to allocate the resource storage in the
system heap before adding it to the system file.  Then the
ReleaseResource becomes unneccessary.

Thanks for the corrections.  They've spurred me on to a better
understanding of MultiFinder.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Americans will buy anything, as long as it doesn't cross the thin line
 between cute and demonic." -- Ian Shoales