Re: Data vs. Resource
Re: Data vs. Resource
- Subject: Re: Data vs. Resource
- From: Matt Neuburg <email@hidden>
- Date: Mon, 13 Mar 2006 16:19:39 -0800
- Thread-topic: Data vs. Resource
On Sun, 12 Mar 2006 02:44:29 -0700, Gnarlodious
<email@hidden> said:
>What are the relative pros and cons of the "Resource Fork" script versus the
>"Data Fork" script"? Is Apple moving in one direction? I confess I'm
>befuddled by the option.
I think I weigh the pros and cons pretty well in my book. I quote in full
from pages 56 and 57:
======
Resource-fork file
The bytecode is kept in the file¹s resource fork; there is no data fork. The
type is 'osas'; the extension is .scpt. Historically, this is the oldest
form. Script Editor will not create a file in this form (though Script
Debugger can), but if Script Editor encounters such a file it can open,
edit, and save it in the same form.
Data-fork file
The bytecode is kept in the file¹s data fork. (There may be a resource fork,
but it¹s for other things, such as the script¹s description and window
state.) The type is 'osas'; the extension is .scpt. This is the default form
created by Script Editor, where it is called simply ³script²; Script
Debugger calls it ³Compiled Script (Data Fork).²
Script Bundle
The bytecode is kept in the data fork of a file called main.scpt, which has
no resource fork and lives inside the Contents/Resources/Scripts folder of a
bundle. (A bundle is a folder that is presented through the graphical user
interface as a file.) Other information is stored in the data fork of other
files in the bundle; the description, if any, lives in a file called
description.rtfd, and window state is stored in the bundle¹s Info.plist. The
bundle can be used to hold further ancillary resources (an example appears
in Chapter 25). Script Editor calls this format ³script bundle²; Script
Debugger calls it ³Compiled Script (Bundle).²
Originally there was just one compiled script format the resource-fork
file. Life was simple: any context that might open a compiled script file in
order to run it (technically known as loading the script) could be relied
upon to deal with any compiled script file whatsoever. Then when Mac OS X
came along, there was a general move to eliminate use of the resource fork
everywhere; this resulted in the data-fork file format. Finally, Panther
introduced the script bundle format, along with some system functionality
that in theory would allow an application to load a compiled script file
without worrying about its format.
A resource-fork script file and a data-fork script file look exactly the
same from the outside, so to distinguish them you have to be sneaky. You can
do it using the command line in the Terminal; an easy GUI-based alternative
is HexEdit (http://www.ifd.com/hexedit).
Two kinds of problem have resulted from this proliferation of compiled
script file formats. The first has to do with backwards compatibility. A
script bundle can¹t be opened on any system before Panther (Mac OS X 10.3).
A data-fork file can¹t be opened on most preMac OS X systems. But those are
the only two formats that Apple¹s Script Editor can create, so any compiled
script file created by Script Editor will lack some backwards compatibility.
(To be precise about data-fork file compatibility, a data-fork file created
by the current Script Editor can usually be opened by Script Editor 1.8.3 on
a preMac OS X system. But if you go back any further, to Script Editor
1.4.3 which was the standard as recently as the early days of Mac OS 9
it won¹t be able to open it.)
The second problem is that some applications in common use predate the
development of one or both of the more recent formats, or for some other
reason fail to take proper account of the multiplicity of possible formats.
So, for example, Entourage X can¹t deal with data-fork scripts, and
Entourage 2004 can¹t deal with script bundles. (In fact, iTunes doesn¹t deal
very well with script bundles either.) NSAppleScript (used by Cocoa
applications to load compiled scripts) can deal with resource-fork files in
Tiger, but couldn¹t do so in Jaguar (Mac OS X 10.2). This puts the onus on
the programmer to make sure the intended script file format will work
properly in the particular context where it is to be run, while longing for
the good old days when a script was a script was a script.
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden