Tips & Tidbits

By Steve Sisak

Avoid RemoveResource, It’ll Get You

I helped a friend with this recently:

Avoid RemoveResource (or, if you’re nstlgic for stupid names, RmveResource) if possible. If you need to replace a resource, like in a preference file, then resize the resource handle if necessary, copy the new data into it, and write it out. This tends to increase very slightly the possibility “of out of memory” failures due to heap fragmentation, but it avoids the only situation (to my knowledge) where using Resource Manager calls in a straightforward way leaves you open to file corruption. RemoveResource immediately shortens the resource file by the length of a resource map record. If the catalog is flushed, and you then crash or otherwise terminate a program without calling UpdateResFile, you’re hosed. Parts of the resource map at the end of the file are snipped off, very likely rendering the file unusable by the resource manager.

I encapsulated the resize/copy/write stuff into a routine I called ReplaceResource. If you use RemoveResource/AddResource and crash, you could lose the whole file. If you use ReplaceResource and crash, all you’ll lose is the recently added data. I like the failure mode where I get to keep most of my data.

(Historical anecdote: I learned about this behavior during System 7 development. The bug report said something like, “Changing the control panel settings and then hitting the reset switch makes the system fail to boot.” The system file was being shortened by the RemoveResource calls. I think we fixed it by calling UpdateResFile(2) immediately after removing and adding new resources, mostly because it was the quickest way to get that bug out of our faces and move on to the other two or three thousand. I recommend the ReplaceResource”approach, though, because there are times when calling UpdateResFile isn’t appropriate for performance reasons and it’s good to use one technique everywhere, instead of “sometimes you do this, sometimes you do that...”)

Greg Marriott

Fat Apps Can Purge Unwanted 'CODE's,
(But They’ll Still Be Fat)

I can’t remember who came up with this one originally, but it’s a good one:

68K development environments like to mark your first one or two 'CODE' segments as preloaded. For fat applications, though, these resources just take up valuable heap since, they never are used but don’t get purged.

Something like the following should fix the problem:

#if GENERATINGPOWERPC
 Handle h;
 h = Get1Resource( 'CODE', 0 );
 if ( h ) ReleaseResource( h );

 h = Get1Resource( 'CODE', 1 );
 if ( h ) ReleaseResource( h );
#endif

Note that it is important to use GENERATINGPOWERPC instead of GENERATINGCFM, because it is possible for GENERATINGCFM to be defined under 68K as well. And if you are building a 68K CFM app, you still end up using code segments....

Eric Shapiro

[Special thanks to Allan Foster and Marshall Clow on this one - the reward is being donated to charity. - sgs]