Resource Manager Q&As

Technote TB 555October 1990

Revised by: Developer Support Center September 1993
Written by: Developer Support Center October 1990

This Technical Note contains a collection of archived Q&As relating to a specific topic--questions sent the Developer Support Center (DSC) along with answers from the DSC engineers. Current Q&A's can be found on the Macintosh Technical Q&A's web site.

Order of resources retrieved by GetIndResource

Date Written: 1/21/93

Last reviewed: 4/26/93

When GetIndResource is called, does the Resource Manager return the resource with the lowest ID? Is it possible to predict the order of resources returned by GetIndResource call?


GetIndResource returns resources in the order that they were added to the resource file, not by ID number. If you want to retrieve resources in a specific order by ID number, use GetIndResource and GetResInfo (Inside Macintosh Volume I, page 121) to build a list of resources and ID numbers, and then sort the list and start retrieving based on your criteria.

Theoretically, if you add resources in a certain order, GetIndResource will give them back to you in the same order. However, this is subject to change, which is why we recommend the above approach.

Macintosh resource ID numbering

Date Written: 7/26/90

Last reviewed: 6/14/93

Does the warning about using Macintosh resource IDs 0 through 127 apply to resource types of my own design?


When numbering resources, you can use any number you like on resource types of your own creation (that is, not of a type reserved by Apple.)

In numbering resources you create of a type reserved by Apple, stick to the following guidelines:

* Negative numbers are reserved for various owned and otherwise "encoded" resources.

* The numbers 0-127 are reserved for Apple's use.

* Positive numbers >127 are available for your use.

* DTS no longer registers 'FOND' IDs. 'FOND's should be referenced by name and not by number because the numbers change. Choose any 'FOND' ID within your font's script range. For details, see the Macintosh Technical Note "Font Family Numbers."

Locate Macintosh folder first with FindFolder before OpenRFPerm

Date Written: 12/4/90

Last reviewed: 12/19/90

OpenRFPerm gets result code -43 (file not found) when opening a file that was put in the Macintosh System 7 Control Panel folder, but when the file is moved outside the Control Panel folder and within the System Folder, OpenRFPerm works fine.


It sounds like you are calling OpenRFPerm and it is accessing the System Folder rather than the Control Panel Folder. System 7.0 doesn't automatically search all of the subfolders in the System Folder; therefore, it is necessary to use the toolbox call FindFolder to locate the Control Panel folder before you call OpenRFPerm.

The FindFolder call is documented in Inside Macintosh Volume VI, Chapter 8: "You can call the FindFolder function to get the path information so that you can access special folders. You pass FindFolder a target volume and a constant that tells it which special folder you are interested in. FindFolder returns a volume reference number and a directory ID. If the specified folder does not exist, FindFolder can create it and return the new directory ID. (See table 8-2 for the folder types [in System 7.0], resource types and constants.)"

HOpenResFile with fsRdPerm permission returns unique path

Date Written: 1/21/91

Last reviewed: 2/13/91

According to the Macintosh Technical Note "OpenRFPerm: What your mother never told you," "OpenRFPerm will create multiple, unique, read-only access paths to a resource file." Is this same behavior present in HOpenResFile? A cdev I have written must look within certain types of files for specific resources. If the file is already open, will a call to HOpenResFile with fsRdPerm permission return a unique path? Using OpenRFPerm seems to have no problems, but the overhead of creating working directories seems rather untidy.


HOpenResFile is simply a friendly face on top of OpenRFPerm, so the unique access paths that are created by OpenRFPerm will indeed percolate upward through HOpenResFile.

Changing a Macintosh resource

Date Written: 4/15/91

Last reviewed: 6/14/93

What's the recommended way to update a Macintosh resource?


As you may have guessed, there is no standard way to update a resource in a resource file. The general rule of thumb is, if the resource exists, simply load it in, modify it, mark it changed, and then cause it to be written out. It is also best at this point to write the resource if you know you are done changing it (ChangedResource simply schedules the resource to be written the next time the resource file is updated). (Read the caveat about changing purgeable resource on page I-123 of Inside Macintosh Volume I.)

You should, as a general rule, never remove and replace the resource. This causes undue accounting problems for yourself and the Resource Manager, and causes quite a bit more writing to the file than is absolutely needed.

If the write of a resource has failed for any reason and you would like to have the memory version of the resource contain what the disk version does, simply detach the current handle from the resource using detach, dispose of the handle if you don't want the data anymore, and reload the resource as normal.

System 7.0 Resource Manager resource decompression

Date Written: 4/26/91

Last reviewed: 6/14/93

Is the resource compression technique used in System 7.0 documented anywhere?


Documentation describing the compression algorithm used on resources is not available. The System 7.0 Resource Manager automatically decompresses for you. You can force a resource to be permanently decompressed by modifying it with ResEdit. Under System 6.0.7 or earlier systems, there's no easy method to access compressed resources.

HOpenResFile versus OpenResFile

Date Written: 5/1/91

Last reviewed: 6/7/91

Why would using OpenResFile(fileName) cause a crash when I try to open a Macintosh font file that's already open?


The problem stems from the fact that OpenResFile doesn't deal effectively with cases where the resource file is already open. Luckily, there are some relatively new Resource Manager calls that you can and should use instead. They're all documented in the Resource Manager chapter of Inside Macintosh Volume VI and in the Macintosh Technical Note "New Resource Manager Calls."

The call of interest in your case is HOpenResFile. To use it, break down the vRefNum (actually WDRefNum) returned by Standard File into a real vRefNum and dirID by calling PBGetWDInfo, and pass those to HOpenResFile along with the file name. The important part, however, is the permissions byte. If you expect to modify the file, pass fsRdWrPerm in that field. If there's an error of any kind, expect HOpenResFile to return -1, which should serve as a signal that you need to call ResError to find out what went wrong.

Partial resources and compressed resource format

Date Written: 8/9/91

Last reviewed: 9/24/91

The partial resource calls ReadPartialResource and WritePartialResource do not decompress Apple's compressed resource format. In fact, these two calls are the only way possible to read resources without decompressing them. It is not really possible to decompress part of a resource, since the decompression method requires the entire resource to be in memory for the conversion to occur.

Details of Apple's compression scheme are not documented and Apple doesn't currently license the algorithm to developers, but Macintosh compressed resources are contained only in the System file and other Apple-specific files. Because third-party products don't use Apple's compressed resources and all Apple's compressed resources fit in memory without the partial calls, you needn't worry about supporting partial resource calls with compressed resources. Just use the standard GetResource call to load these Apple-compressed resources. You can determine if a resource is compressed by examining bit 0 of the resource's attributes. If this bit is set, the resource is compressed, and partial resource calls will return the compressed data.

Getting Macintosh system strings

Date Written: 1/18/92

Last reviewed: 2/6/92

Our application needs to know the Chooser Name and Machine Name, stored as 'STR ' resources in the System file. If I do a GetResource to read one of these (they are loaded into the system heap), should I do a ReleaseResource when I am done? The resources are not purgeable so they won't go away by themselves. On the other hand, I'm worried about releasing them out from under something else that has the same resource handle (like the Chooser or the Finder).


The Chooser Name and Machine Name resources should be treated a little differently from normal resources under System 7. You really should use GetString, instead of GetResource to get the string (although GetString simply calls GetResource). Once you have the string you should not release, dispose or make purgeable the string. You will find that the string was already loaded when you asked for it, so it should remain when you are done. Also, you should never change the contents of, or mark as changed, either of these strings since the Chooser could be open and would not recognize your changes, unless you give your users sufficient warning of the potentially confusing side effects of having a different name in two places. Keep in mind that System 6 does not necessarily have the Computer Name resource, so do error checking...

Bottom line: Get but don't release these special strings, and don't modify them unless absolutely needed.

Pre-load resources & calling OpenResFile on another application

Date Written: 2/27/92

Last reviewed: 6/12/92

My application wants to open other applications and play with the resources therein, like ResEdit, but when it calls OpenResFile on an application, the program gets lost in GetNamedResource. Is there something I'm missing?


Your problem stems from the fact that some resources in the application file you're opening with OpenResFile are marked to be preloaded, and so are loaded into memory when the resource fork is opened.

Since most applications have CODE resources marked to be preloaded, this turns into a much bigger problem, because the Segment Loader will treat these preloaded CODE resources as your code resources if you make a between-segment call that triggers a call to LoadSeg while the opened resource file is first in the resource chain. If this happens, you'll begin executing code out of the other application, which will cause your Macintosh to crash and burn.

The solution to this problem is to bracket OpenResFile calls with SetResLoad(FALSE) and SetResLoad(TRUE), and to avoid making between-segment calls when you've got another resource file open that contains CODE resources. This will not only prevent your application's memory from being used by preloaded resources that you don't want, but will also prevent the Segment Loader from jumping into the other application's code. If you need to get CODE resources out of the opened resource file, you can still prevent the Segment Loader problem by calling UseResFile on your application's resource reference number to put your application at the top of the resource chain.

Maximum number of items in a Macintosh resource file is 2727

Date Written: 5/22/90

Last reviewed: 12/17/90

Is there a maximum number of items for Macintosh resources?


In a file, yes. It is 2727.


Macintosh Technical Note "Maximum Number of Resources in a File"

Maximum Macintosh resource size is "maxlongint" bytes

Date Written: 5/22/90

Last reviewed: 12/17/90

Is the maximum size of a Macintosh resource still 32K?


No. There used to be a bug in the 64K ROMs that didn't allow you to write even multiples of 32K, such as 32K-64K or 128K-192K. This bug was fixed in 128K ROMs. As of 128K ROMs, the resource size is limited to "maxlongint" bytes.

Previous Technote | Contents | Next Technote