• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Resource Fork - is this a good use/the right thing to do?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Resource Fork - is this a good use/the right thing to do?


  • Subject: Re: Resource Fork - is this a good use/the right thing to do?
  • From: Uli Kusterer <email@hidden>
  • Date: Thu, 24 Apr 2008 11:52:41 +0200

Am 24.04.2008 um 09:16 schrieb Daniel DeCovnick:
I read that. I'm not sure I completely know what the resource map is. The resource manager keeps track of a table of resource types, and subtables of resource names or ID's as the key in a key-value pair, where the resources themselves are the values. Is that what the map is, that whole data structure that the manager keeps track of?

Yes. The resource map is the table of contents of a resource file. It uses offsets into the file to point from the type, ID number (and optional name) of a file to its actual contents. Since resources have been around pretty much since the days of the first Macintosh operating system, they use rather small number types for today's computers.


FWIW, as far as manipulating resource forks go, I was planning to use the NDResourceFork classes (see further up this thread about 20 posts). If what that does is the wrong way to go (I suspect it's not), let me know. And, if I'm wrong about what the map is, if by using NDResourceFork I don't need to concern myself with what a resource map actually is so long as I make sure I stick to my own crazy 4-char resource type (say, dåNd, or s¥$w) and valid resource ID ranges, let me know that also. :-)

Apple has documentation about what resource types are reserved for use by Apple. IIRC they must contain at least one uppercase character. I'd recommend you use the signature registry on Apple's web site to register a signature, and use that. That decreases chances of your type colliding with any in use. Though you'll still have to make sure it doesn't collide with a well-known resource type. Check out the Cocoa-Dev and Carbon-Dev archives, there was a thread on one of these lists whether signatures (creator codes) are still needed today, and we dug out the documentation about what resource types are reserved in the process.


And if I do have a substantial part of that right, what are the limits I need to worry about? Uli mentioned a limit of 2727 resources per fork. While that seems absurdly low, it's not like I'd be using a resource for every piece of data I need to keep track of.

It's a technical limit. That's the point at which one of its offsets overflows, IIRC. You need to be careful with that, as the resource manager will simply crash when you exceed that.


Far simpler just to serialize my data and write it to a single resource if that sort of limit exists; shove my XML or binary data into blah.blah>resource fork>s¥$w>128. I know that a single resource can be at least 3 MB*. What's the limit there, for instance?

I'll try if I can find a backup of my blog posting on the topic. I don't have the nerve to go back to Inside Macintosh: More Macintosh Toolbox to re-read the documentation of the resource file format. However, if anyone else wants to, the format is documented here:


	http://developer.apple.com/documentation/mac/MoreToolbox/MoreToolbox-99.html#HEADING99-0

One of the limits that immediately comes to mind is that the beginning of the resource map has to be within 64k bytes from both the resource type list and the name list, which puts a hard limit on the size of the resource map (see Fig. 1-14). Similar limits seem to be on the name list and a few other lists. Note that the 2727 limit is a "well- known bug", so to say, I don't think Apple has documented it anywhere.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de





_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Resource Fork - is this a good use/the right thing to do?
      • From: Daniel DeCovnick <email@hidden>
References: 
 >Resource Fork - is this a good use/the right thing to do? (From: Daniel DeCovnick <email@hidden>)
 >Re: Resource Fork - is this a good use/the right thing to do? (From: Jens Alfke <email@hidden>)
 >Re: Resource Fork - is this a good use/the right thing to do? (From: Daniel DeCovnick <email@hidden>)
 >Re: Resource Fork - is this a good use/the right thing to do? (From: Uli Kusterer <email@hidden>)
 >Re: Resource Fork - is this a good use/the right thing to do? (From: Daniel DeCovnick <email@hidden>)
 >Re: Resource Fork - is this a good use/the right thing to do? (From: Chris Suter <email@hidden>)
 >Re: Resource Fork - is this a good use/the right thing to do? (From: Graham Cox <email@hidden>)
 >Re: Resource Fork - is this a good use/the right thing to do? (From: Chris Suter <email@hidden>)
 >Re: Resource Fork - is this a good use/the right thing to do? (From: Graham Cox <email@hidden>)
 >Re: Resource Fork - is this a good use/the right thing to do? (From: Daniel DeCovnick <email@hidden>)
 >Re: Resource Fork - is this a good use/the right thing to do? (From: Chris Suter <email@hidden>)
 >Re: Resource Fork - is this a good use/the right thing to do? (From: Daniel DeCovnick <email@hidden>)

  • Prev by Date: Re: Resource Fork - is this a good use/the right thing to do?
  • Next by Date: Re: Uneditable NSTableView
  • Previous by thread: Re: Resource Fork - is this a good use/the right thing to do?
  • Next by thread: Re: Resource Fork - is this a good use/the right thing to do?
  • Index(es):
    • Date
    • Thread