All Databases MacTech Vol 12-1996

Apr 96 Tips

Volume Number: 12

Issue Number: 4

Column Tag: Tips & Tidbits

Tips & Tidbits

By Steve Sisak

Note: Source code files accompanying article are located on MacTech CD-ROM or

source code disks.

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]

Referenced by (4):