Cocoa mail archive
Re: Resource Fork - is this a good use/the right thing to do?
FROM : Daniel DeCovnick
DATE : Thu Apr 24 13:08:00 2008
The tips are appreciated. AFAICT, the limit on total resource sizes is
within a kB or 2 of 2 or 4 GB, with the limitation that the last
resource must start within the first ~16 MB. Given the fact that the
files I'm opening are in the 1-300k range, I suspect I have bigger
problems than the resource file format if I start to approach that
limit.
One thing I can't figure out though... why is the limit 2727? Assuming
you have only 1 resource type and no names, you can fit exactly twice
that many references in the map. It's not relevant to my problem, but
I am curious.
-Dan
On Apr 24, 2008, at 5:52 AM, Uli Kusterer wrote:
> 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
>
DATE : Thu Apr 24 13:08:00 2008
The tips are appreciated. AFAICT, the limit on total resource sizes is
within a kB or 2 of 2 or 4 GB, with the limitation that the last
resource must start within the first ~16 MB. Given the fact that the
files I'm opening are in the 1-300k range, I suspect I have bigger
problems than the resource file format if I start to approach that
limit.
One thing I can't figure out though... why is the limit 2727? Assuming
you have only 1 resource type and no names, you can fit exactly twice
that many references in the map. It's not relevant to my problem, but
I am curious.
-Dan
On Apr 24, 2008, at 5:52 AM, Uli Kusterer wrote:
> 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
>
