Re: Write a prefs file
Re: Write a prefs file
- Subject: Re: Write a prefs file
- From: Matthew Stuckwisch <email@hidden>
- Date: Fri, 31 May 2002 00:26:50 -0500
Come on. Don't follow blindly - learn about the subject!
The fact is many current Mac OS X apps (even system apps that come with
Mac
OS X) contain resources in the resource fork of a resource file within
the
bundle.
Don't believe me? Take a look at iTunes, IE, QuickTime Player,
Sherlock,
Terminal, the list goes on. Each of these apps contain resource files
with
entire collections of resources in them.
True, but none of those applications contain any resource forks. The
distinction here, which a lot of people miss, is between a resource
*fork* and a resource *file*. Apple tends to not use resource forks for
anything. There are currently a few exceptions, like AppleScript
applets, but that was a deliberate choice made for backward
compatibility.
I apologize ahead of time for contradicting you, Chris, but this is
incorrect. Every one of the applications I listed have files with
resource
forks:
iTunes.app/Contents/Resources/iTunes.rsrc
iTunes.app/Contents/Resources/English.lproj/Localized.rsrc
iTunes.app/Contents/MacOS/CD\ Lookup\ Library
Okay, you get one, but trust me, this is all you're getting. This one
does indeed have resource files with a data fork of 0 byte.
Internet\ Explorer.app/Contents/Resources/Internet\ Explorer.rsrc
Internet\ Explorer.app/Contents/Resources/English.lproj/Localized.rsrc
QuickTime\ Player.app/Contents/Resources/QuickTime\ Player.rsrc
Sherlock.app/Contents/Resources/Sherlock.rsrc
Terminal.app/Contents/Resources/Terminal.rsrc
All of these however have data fork resource files anywhere from 3
kibibytes to several mebibytes
Heck, even all AppleScript applications (applets) have resource forks with
many many resources in them.
He admitted that these still use resource forks.
(there are also more apps than I have mentioned; but you get the general
idea...)
Resource Manager resources, on the other hand, are just fine [1]. The
trick is that they're now typically stored in the data fork.
No resources are not typically stored in the data fork - they are still
stored in the resource fork in most of the apps I have seen in Mac OS X.
Definitely not in the apps I will be writing / maintaining for Mac OS X
in
the near future. All of the resource files I have mentioned are real
resource files with resource forks containing actual resources (lots of
them, in fact).
I think here you have forgotten that applications in OSX are no longer a
single data file. They are actually folders that Finder interprets as a
file. You've shown you know how to use the terminal based on your file
listing, so try this:
> cd /Applications
> ls -F
How many of these applications are foo.app*, which would go to say that
they have a resource fork? Unless you've got some classic and MAYBE some
carbon apps in there, none should end in a *, but rather be foo.app/ which
means the terminal is interpretting them as a directory, which they are.
This is no different then Finder hiding a file .foo or .bar, where the dot
signifies being hidden, which again the Terminal can output just fine, try
ls -a. What it seems you are trying to say is that since you can find the
resource files inside an application package they are instantly in a
resource fork.
If you look inside, say, Terminal, you'll see a file Terminal.rsrc. If
you
inspect it, you'll discover that it has no resource fork, and the data
fork
contains all the bits that would historically have been in the resource
fork.
You can see the resources themselves using DeRez -useDF.
In Mac OS X 10.1.4, Terminal.rsrc doesn't even have a data fork, and ONLY
contains a resource fork with a single "aete" resource ID 2750.
do this:
> cd /Applications/Utilities/Terminal.app/Contents/Resources
> ls -ls
[snip]
-rw-rw-r-- 1 root admin 3081 Sep 7 2001 Terminal.rsrc
[snip]
Explain to us how a a non-existant data fork can have a size of 3081. A
real no-data, all-resource file (like iTunes) should show up to the ls
command as having a size of 0.
[1] There are improved replacements for several common types of
resource (e.g., .strings files instead of STR# resources, nibs vs.
DLOG/DITL/etc.) Developers not obliged to use them, but they have their
advantages.
These data-fork replacement files have distinct disadvantages as well.
Off
the top of my head:
To convert a single resource file/fork containing sometimes hundreds or
even
thousands of resources to the "new and improved" data fork implementation
means splitting those resources up into many files - one resource per
file,
due to data fork limitations. The result, the file system must do more
work
to read them. The busier the file system, the slower the performance.
Reading the files is also slower than reading resources because the disk
has
to move around more to find the files. Also, as a developer, you lose a
heck of a lot of the the niceties the Resource Manager provides - for
example, organization, easy retrieval, etc. There are of course more
disadvantages that I won't take the time to get into.
In this case I believe the advantages outweigh the disadvatages, but this
is a matter of personal opinion.
All in all, I have yet to see enough advantages to outweigh the many
disadvantages. And frankly, until I see Apple eat it's own dog food, I
ain't
scarfing it down myself.
As you can see, Apple is eating it's own dog food, except for the iTunes
team, which reminds me. You've mentioned speed issues with using data
forks instead. Seems of the OSX-savvy programs I've got, iTunes is one of
the slowest, and it uses resources in a resource fork. You honestly haven'
t made the best case in the world on this issue.
Matthew Stuckwisch
[AIM/MSN]{GuifaSwimmer} | [Yahoo!]{SapphireTree} | [ICQ]{137477701}
[IRC]{guifa / G}(esperNET / irc.massinova.com)
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.