AppleScript 1.6 (Mac OS 9.1 and 9.2.1 and OS X 10.0 Cheetah)

Bill_Cheeseman · September 26, 2001, 2:07am

TESTING WHETHER APPLESCRIPT 1.6 IS INSTALLED

Before using new features of AppleScript, careful writers of scripts intended for public distribution will want to determine which version of AppleScript is present on the user’s machine. This task has become more complicated with the advent of Mac OS X, due only in part to the fact that different flavors of AppleScript 1.6 are installed in the Classic environment and in the Mac OS X environment. In addition, unfortunately, two bugs in Mac OS X 10.0 make the task still more difficult, especially if what you want is a script that will run correctly in the Classic environment as well as under all other versions of the Mac OS.

The standard technique for determining the version of AppleScript in Mac OS 9.1 and earlier utilizes the Finder’s Computer command, as explained in The AppleScript Sourcebook’s report on AppleScript 1.3.4 (the technique was slightly modified for AppleScript 1.5.5, in a backward-compatible fashion). Although the Computer command has been eliminated from the Finder’s dictionary both in the Mac OS X environment and in the Classic environment, a new System Attribute command that is almost identical has been added to Standard Additions in the Mac OS X environment. As a result, after tweaking it to work around the two new bugs, the basic approach of the standard technique continues to work in Mac OS X. Apple’s discussion of the new System Attribute command does not address the bugs described here.

A first cut at adapting the standard technique for use in Mac OS X simply eliminates the Finder Tell block, as shown in the following script. The integer, 17826144, stands for version 1.6, in Apple’s decimal-coded hexadecimal versioning scheme.


if system attribute "ascv" is greater than or equal to 17826144 then 
		 -- statements using AppleScript 1.6 or newer
	else 
	 	-- statements using older versions of AppleScript
end if

However, to enable this script to run under older versions of the Mac OS, as well, where Standard Additions did not implement the System Attribute command, it must still be enclosed in a Finder Tell block. Apple cleverly engineered the new System Attribute command so that it uses the same raw event code internally that was used by the Finder’s Computer command. As a result, if you enclose the System Attribute command in a Finder Tell block and run the script on an older system without recompiling it, it will automatically invoke the Finder’s Computer command and return the correct result. (To prove to yourself that the codes are identical, write the above script in the Mac OS X Script Editor using the Computer command instead of the System Attribute command. When you compile it, computer will change to system attribute. If you then move the compiled script to a Mac OS 9.1 or older machine and compile it with an older version of Script Editor, it will revert to computer.) Enclosing the System Attribute command in a Finder Tell block is harmless when a script is run under Mac OS X so, whenever backward compatibility might be required, it is advisable always to enclose a call to System Attribute in a Finder Tell block. In short, the standard technique for determining the version of AppleScript still applies in Mac OS X except for two problems.

The first bug that mars this very nice arrangement causes the System Attribute test for AppleScript 1.6 to return an incorrect value when run in the Mac OS X environment. Apple discovered this issue too late to correct the error before releasing Mac OS X for production, although it is mentioned in an AppleScript bug list on the Developer Tools CD. The command ‘System attribute “ascv”’ returns 17826128, which in decimal-coded hex is 01100150, meaning version 1.5. It should return 17826144, which is the integer equivalent of decimal-coded hex number 01100160, meaning version 1.6. (If you run the same test with the promised AppleScript 1.6 upgrade installed on a machine booted directly into Mac OS 9.1, I believe it will return the correct result.)

To work around this bug and test for AppleScript 1.6 in the Mac OS X environment, you can test the version of the system that is currently running in addition to testing the AppleScript version, but you need do so only if ‘System attribute “ascv”’ returns 17826128. If the system version is 10.0 or greater (that is, ‘System Attribute sysv’ returns 4096 or greater), then you can be confident that AppleScript 1.6 or newer is running, not AppleScript 1.5.

The following handler covers all of these angles:


on AppleScript16OrNewer() 
	tell application "Finder" to get system attribute "ascv" 
	if result is greater than or equal to 17826144 then 
		return true 
	else if result is equal to 17826128 then 
	tell application "Finder" to get system attribute "sysv"
		return (result is greater than or equal to 4096) 
	else 
	return false 
end if
end AppleScript16OrNewer

Unfortunately, however, a second bug prevents a script that uses this handler from running under AppleScript 1.6 in the Classic environment of Mac OS X, so still more tweaking is required. The version of Standard Additions 1.6 that is installed in the Classic environment does not include the new System Attribute command. In addition, the Computer command has in effect been removed from the Finder’s dictionary in the Classic environment, because the Classic environment uses the Finder 10.0 dictionary. Because of this confluence of dictionary changes in the Finder and Standard Additions, neither the Computer command nor the System Attribute command will compile to executable code if you are using Script Editor in the Classic environment. More seriously, such a script, if compiled under another version of the Mac OS, will error when run in the Classic environment. You therefore cannot run a script in Classic using the standard technique without yet another embellishment. (I brought this bug to Apple’s attention a week before Mac OS X was released to the public. I imagine it can be fixed rather easily, perhaps by adding the System Attribute command to Standard Additions for the Classic environment. Udpates to Mac OS X are rumored, possibly as early as a week after the initial release of Mac OS X. If this bug is fixed promptly, the following workarounds will no longer be necessary.)

The trick is to trap for the error that is generated when the unimplemented Computer or System Attribute command is run in the Classic Environment, error number -1708. The following handler is the new AppleScript Sourcebook-recommended standard technique for determining whether AppleScript 1.6 or newer is present. It cannot be compiled in the Classic environment unless you substitute the raw event code for the System Attribute command, but it will run there and return the correct result. Note, however, that it is not foolproof; it assumes that nobody would install an older version of AppleScript in the Classic environment. It is likely to continue to work after Apple fixes these bugs in a later release of Mac OS X.


on AppleScript16OrNewer()  try
	tell application "Finder" to get system attribute "ascv" 
	if result is greater than or equal to 17826144 then 
		return true 
	else 
	if result is equal to 17826128 then 
	tell application "Finder" to get system attribute "sysv"
	return (result is greater than or equal to 4096) 
	else 
		return false 
	end if 
on error number -1708
	return true 
end try
end AppleScript16OrNewer

There are workarounds if you must use the Classic environment to write your script. You can, for example, write and compile a script with the Classic Script Editor using the raw event code, <>; the resulting script will run in the Mac OS X environment and in Mac OS 9.1 and earlier, but it will not run in the Classic environment. A workaround that will run in the Classic and Mac OS X environments and under Mac OS 9.1 and earlier is to get ‘AppleScript’s version’. Note, however, that this returns a string (e.g., 1.6) instead of the familiar decimal-coded hex value returned by the old Computer command and the new System Attribute command. Comparison of AppleScript version strings against a target string value must rely on alphabetical ordering (this should work correctly until AppleScript reaches version 10). Alternatively, you can use the Info For command from Standard Additions to get the Short Version property of the AppleScript system extension under the Classic environment and Mac OS 9.1 and earlier. However, this requires checking the Mac OS X AppleScript.component file separately, if the script is to work in the Mac OS X environment, too. Although the Short Version property can be coerced ‘as real’, it must be coerced ‘as string’ in order to deal, for example, with AppleScript 1.5.5, because 1.5.5 is not a number. The most satisfactory workaround is probably to write all your scripts in the Mac OS X environment. However, if your Mac OS X script needs to use scripting additions or scriptable applications that are available only in the Classic environment, you will face additional complexities, including figuring out how to use the Using Terms From construct described above.

After all of this work to ensure backward compatibility of the version test, you are still left with one potentially serious problem: existing older script applications. If an older script saved as a classic script application (i.e., not as a Mac OS X Applet) is run on a Mac OS X machine, it will automatically run in the Classic environment. Since neither the Finder’s Computer command nor the System Attribute command exists in the Classic environment, the script will fail with runtime error number -1708, ‘ascv’ doesn’t understand the <> message. This will happen with all older applets that were written using the Finder’s Computer command, including the version-testing technique recommended here over the last several years, as well as with new Classic applets using the System Attribute command written in the Mac OS X environment. This is why Apple must fix this bug promptly. In the meantime, if you have editing access to such a script, you can fix it in one of two ways: by recompiling it as a Mac OS X applet so that it will run in the Mac OS X environment, or by editing it to test for error number -1708 and concluding, if the error is trapped, that the script is running in the Classic environment of Mac OS X. If you don’t have editing access to the script, it simply won’t work on a Mac OS X machine, despite the lengths to which Apple has gone to provide the Classic compatibility environment, and there is nothing you can do about it except wait for Apple’s bug fix. I don’t know how many existing applets fall into this category or how essential they may be to their users, but it is a potentially serious backward-compatibility problem for the time being.

Here is a handler that can be used to determine whether a script is running in the Mac OS X environment, or in the Classic environment, or in Mac OS 9.1 standalone. It is offered only as a starting point. It does not take account of the possibility that it might be running on an older or newer system, nor of the possibility that Apple will fix the bug whereby neither the System Attribute nor Computer commands exist in the Classic environment. Refine it to suit your purposes and use it with care.


on MacOSVersion()
	tell application "Finder"
		try
			get system attribute "sysv"
			if result is equal to 4096 then
				return "Mac OS X environment"
			else if result is equal to 2320 then
				return "Mac OS 9.1"
			end if
		on error number -1708
			return "Classic environment"
		end try
	end tell
end MacOSVersion

Bill_Cheeseman · September 26, 2001, 2:10am

WHERE APPLESCRIPT ITEMS ARE LOCATED

As with Mac OS X generally, users will have to get used to a new and unfamiliar directory structure relating to AppleScript. Helpfully, the Path To command in the Standard Additions scripting addition can be used to generate a path to some AppleScript-related folders and applications, as well as other important system locations. For example, ‘path to scripting additions’ (or ‘path to scripting additions folder’) returns an alias to the Scripting Additions folder where Apple’s scripting additions are located and available to all users of the machine; namely, alias :System:Library:ScriptingAdditions:. For additional Path To parameters, see Standard Additions scripting addition.

Apart from the fact that all of the locations for system software are new, the most startling change from the classic Mac OS is that there can be many copies of specific system folders in Mac OS X. To understand this, you must become familiar with the basic Mac OS X notion that each user on this multiuser operating system has his or her own Home folder, which contains Documents, Library and other subfolders whose contents are available only to people who log in as that user (and to the system Administrator). This is known as the user domain. The Library folder is particularly interesting from an AppleScripter’s point of view, because this is where a user’s personal system-related items are located, such as scripting additions. There are also Library, Applications and other folders at the root level of the Mac OS X disk; the root-level, or main, Library folder is where system-related software available to all users on a single computer can be installed, including scripting additions. This is known as the local domain. There is also a Library folder in the System folder at the root level of the Mac OS X disk, where Apple-installed system software is located, including scripting additions; users cannot alter the contents of folders in this System domain. Finally, there may be a network domain where Applications, Library and other folders exist that are available to users from a network server. Scripting additions can be installed here, as well. Not all locations are visible or available to all users.

Here are the important Mac OS X AppleScript locations:

Script Editor resides in the AppleScript folder in the Applications folder at the root level of your Mac OS X disk, where it is available to all users. Scripters may find it convenient to drag the Script Editor icon to the Dock so that it is more easily available, unless and until they switch to some other editor. The Script Editor Help command in its Help menu takes you to the AppleScript Help topic using the Apple Help Viewer. The Open Dictionary command in Script Editor’s File menu opens a dialog listing available scriptable applications and scripting additions in alphabetical order. Classic scripting additions apparently are not included in the list, but scriptable Classic applications are listed (including some, such as iTunes, that have empty ‘aete’ resources). Having the scriptable applications listed in this manner makes it much easier to open dictionaries, since you don’t have to dig through a folder hierarchy to find them. Each user’s Script Editor preferences are in the com.apple.scripteditor.plist file in the Preferences folder of the Libary folder in the user’s Home folder, so multiple users can set their own individual preferences. Like many Mac OS X application preferences files, this is an XML file that can be read in TextEdit or the PropertyListEditor utility installed using the Developer Tools CD; don’t change it unless you know what you’re doing. The AppleScript folder is found in the Applications folder at the root level of your Mac OS X disk. In addition to Script Editor, it contains the Script Runner application and a folder of Example Scripts for use with Script Runner (you must first copy them into the Scripts folder, described next). A Scripts folder is found in the LIbrary folder in each user’s Home folder. This is the folder that holds any compiled scripts that are to be made available in the Script Runner button, whose use is described in detail below. Each user may install a unique set of scripts in his or her Scripts folder. The Scripts folder comes empty, but any scripts can be installed in it. For example, a number of useful scripts, arranged into subfolders such as Basics, Finder Scripts, and Script Editor Scripts, can be copied into it from the Example Scripts folder in the AppleScript folder described above. If you install them in your user domain, it is best to copy them rather than move them, so that additional users of your machine can still obtain copies from the Example Scripts folder (they won’t have access to your domain). Alternatively, create a new Scripts folder in the main Library folder in the local domain and drag the Example Scripts into it; they will then appear in all users’ Script Runner menus. The names of some of these Example Scripts begin with About; they can be run like any other script and will provide brief explanations of the contents of the folder in which they appear. Holding the Command key down while opening the Script Runner menu lets you open a script for editing in its native editor. One of the scripts in the URLs folder takes you to The AppleScript Sourcebook. Note that, because all scripts in the Scripts folder are made available in the Script Runner menu, this is not a good place to put script libraries or other scripts that are not appropriate for use in a menu; for libraries, try the Scripting Additions or Application Support folders, instead. There are useful scripts located in other folders. A large number of ColorSync scripts are in the Scripts folder of the ColorSync folder in the Library folder in the local domain. Several very complex and interesting Image Capture scripts are in the Scripts folder of the Image Capture folder in the local domain’s Library folder; among other things, these scripts showcase how much can be done with the Finder using AppleScript.

A Scripting Additions folder may be found or created in the Library folder in any user’s Home folder, so that individual users may install different sets of scripting additions for their own use. A Scripting Additions folder may also be found or created in the Library folder at the root level of the Mac OS X disk, where scripting additions can be installed and made available to all users of the machine, or in the Library folder at the root level of the Network, where they are available to all users on the network. (Making network scripting additions work is reportedly a task for experts administering a Mac OS X Server machine, or masochists using the NetInfo Manager application installed on a normal Mac OS X machine.) Finally, a Scripting Additions folder exists in the Library subfolder of the System folder, unchangeable by users, where the following Apple scripting additions are installed as part of a standard Mac OS X installation: the ColorSyncScripting 3.1 application, the StandardAdditions.osax 1.6 scripting addition, and the URL Access Scripting 1.0 (v3) application. These scripting additions perform the same basic function as the scripting additions or applications with similar names installed in the Mac OS 9.1 Scripting Additions folder, but they are different kinds of files and are not interchangeable. At this stage, most existing third-party scripting additions will not work in Mac OS X and must therefore continue to reside in the Scripting Additions folder in the System Folder of the Classic environment, for use only with the Classic environment. As time goes by, new scripting additions will become available that run only in Mac OS X, as well as some that will run in both environments. In the case of scripting additions that run in both environments, it is necessary to place a copy both in the Classic environment’s Scripting Additions folder and in appropriate Mac OS X Scripting Additions folders, even if the scripting addition comes in a single file.

The AppleScript extension, known in Mac OS X as AppleScript.component 1.6, is in the Components folder of the LIbrary subfolder of the System folder. OSAApplet.component 1.6 is here, as well. The Mac OS X AppleScript.component file performs the same basic function as the AppleScript 1.6 system extension that is installed in the Mac OS 9.1 Extensions folder, but they are different kinds of files and are not interchangeable.

Each user’s AppleScript Preferences are in the com.apple.applescript.plist file of the Preferences folder in the Library folder of his or her Home folder, since each user may set different preferences. This preferences file comes into existence only after the user has set AppleScript formatting preferences using Script Editor or another editor.

The scriptable Finder is located in the CoreServices folder in the Library subfolder of the System folder. Interestingly, there are two Finders here, one an application whose version is given as Mac OS X Finder, and another, a 4K Classic Application, whose version is given as Mac OS X Fake Finder 1.0. You will also find the scriptable Help Viewer 1.7 application here.

Of interest mostly to developers, the header files for many parts of the system are in the Frameworks folder in the Library subfolder of the System folder, even if you do not install the Developer Tools. These include AppKitScripting.framework and Scripting.framework. See Information for Developers for more AppleScript information of interest to developers.

Bill_Cheeseman · September 26, 2001, 2:19am

APPLESCRIPT TOOLS, SCRIPTING ADDITIONS, AND SCRIPTABLE APPLICATIONS

This section lists applications and other software from Apple that either works with or facilitates the use of AppleScript in the Mac OS X environment, as well as scriptable applications that are installed with Mac OS X. This may seem like faint praise, but I am pleased to report that all of them work. Given the radically different underpinnings of Mac OS X, it is a remarkable accomlishment. (Note, however, that I have not yet exhaustively tested any of them, and I don’t expect all of them to work well.)

First, Mac OS X uses Mac OS 9.1 or newer in the Classic environment, so a machine on which you will install Mac OS X must first contain Mac OS 9.1 or newer that is, if you intend to use the Classic environment; it is not mandatory. To make upgrading easy, the Mac OS X product comes with the standard Mac OS 9.1 installation CD that is available for purchase separately by people who are not upgrading to Mac OS X. If you want to use the Classic environment with Mac OS X and you haven’t already upgraded to Mac OS 9.1, you must do so before you install Mac OS X. This will, of course, upgrade all AppleScript components to their Mac OS 9.1 versions. Note that recent Mac OS 9.1 installation CDs contain newer versions of some items, compared to the versions that were available with the initial release of Mac OS 9.1 at Macworld Expo in early January 2001. I assume that the Mac OS 9.1 CD that comes with Mac OS X is newer, so you may want to use it to update all of your computers to the latest version of Mac OS 9.1, whether you will install Mac OS X on them or not. The Mac OS 9.1 CD that comes with the Mac OS X product reportedly will not boot on the newest machines, like the Powerbook G4. These machines come with Mac OS 9.1 preinstalled, but if you need to reinstall Mac OS 9.1 on one of them, use the Mac OS 9.1 installation CD that came with the machine (version 1.2 came with my new machines).

Installing Mac OS X does not immediately install any new items into your Mac OS 9.1 system. The first time you launch a Classic application after installing Mac OS X, however, you will be asked to permit some Mac OS 9.1 items to be updated and some new items to be installed for use in the Classic environment. Apple assures you that your system will still work properly when you boot directly into Mac OS 9.1 after these changes have been made. Updated items for Mac OS 9.1 in the Classic environment include the new AppleScript 1.6 system extension, the new Standard Additions 1.6 scripting addition, and the new Script Editor 1.6. Although the Finder remains at version 9.1.1, be forewarned that its dictionary looks different when examined within the Classic environment than it does when you have booted directly into Mac OS 9.1. The new features of these Classic items are described in several places in this report, including Dictionary Changes.

Mac OS X installs the AppleScript tools and scriptable applications listed below for use in the Mac OS X environment, in addition to the items mentioned in Where AppleScript Items are Located. In considering the dictionaries of the scriptable software in this list, it is easy to nitpick about signs that some of them were rushed to release without review by experienced AppleScripters, and it is easy to complain about the absence of usage examples or instructions for most of them. Restraint is called for, however. We should be thankful that AppleScript has progressed as far as it has in this first official release of Mac OS X.

We can live for now, for example, with dictionaries whose terminology departs from official AppleScript suites (for example, in Mail and TextEdit, two Cocoa applications, there are several window properties beginning with is, such as Is Zoomed instead of Zoomed, leading to awkward statements like ‘if window 1 is is zoomed’). And we can live with commands in a Required Suite, although the Required Suite was officially discontinued and melded with the Standard Suite some time ago (the Close command appears both in the Required Suite and in the Standard Suite in Print Center). And with dictionaries defining terms that don’t parse according to plain English usage, in contravention of one of AppleScript’s principal goals (the Pref command in Apple System Profiler leads to the vaguely obscene locution, ‘tell application Apple System Profiler to pref’). And with terminology that uses initial caps contrary to AppleScript convention (Show Queue and all of the other commands and parameters in Print Center use initial caps).

When examining an AppleScript dictionary in Script Editor, I have occasionally experienced difficulty seeing the left pane, where the scripting suites and their terminology are listed. This happened after I enlarged a dictionary window and chose Set Default Window Size from the File menu. If you encounter this problem, it is easily cured by resizing the window again until the left pane becomes visible; often, simply clicking on the window’s resizing widget is enough.

Installed Software

Script Runner application
Script Runner 1.0 is a Mac OS X-only application, sporting a funky icon of a rocketship with the familiar AppleScript symbol emblazoned on its side. It enables you to organize a collection of compiled scripts and to run them. It does not have a window of its own, nor a menu in the menu bar, and it does not appear in the Dock. It is instead a small, floating button that can be moved around on the desktop. The button always remains in front of application windows, so it provides a convenient system-wide means of running scripts at any time. You may want to stash it away in a little-used corner of the screen, since it can be hard to spot on a busy patchwork of application windows. Its initial position at startup is quite annoying: near the upper left corner of the screen, obscuring the main window of just about every application you launch, and it does not remember where you put it the next time you start up your computer.

Clicking on the Script Runner button brings up a hierarchical menu listing all of the scripts in the Scripts folders and their subfolders located in the several domains, as well as a command to open the user’s Scripts folder and a Help command. A script can be run by choosing it from this menu, and it can be opened for editing in its native editor by holding down the Command key while opening the menu. When the Scripts folder is open, a script can be dragged in and out of it or placed in a subfolder using the Finder, and the script will appear or disappear from the Script Runner menu or a submenu the next time Script Runner is launched.

Script Runner adds a new dimension to the use of compiled scripts, although it will be very familiar to users of Leonard Rosenthol’s OSA Menu for the classic Mac OS. In a bare-bones installation of Mac OS 9.1 and earlier, compiled scripts, unlike script applications, could not be run independently but only within a script editor. To run a script independently, it had to be saved as a script application or applet, and launching one of these entailed the slight delay associated with the launching of any application. For the last few years, Apple’s Mac OS installation CDs have included an optional lite version of OSA Menu, which enabled compiled scripts to be quickly and conveniently run from a menu at the right end of the menu bar without launching an application. A number of other third-party launcher palettes, Apple Menu enhancers, and control strip modules provide similar features. For a while, OSA Menu even included an application called Script Runner that worked something like the new Script Runner in Mac OS X. Scripters will find Script Runner to be an essential part of their Mac OS X experience.

Out of the box, there are no scripts in the Mac OS X Scripts folder in the user domain, and there is no Scripts folder in the System or local domains. However, a number of useful scripts are included in an Example Scripts folder in the AppleScript folder, and all of them work well with Script Runner. If you are a heavy AppleScript user, one of your first Mac OS X setup tasks should be to copy the entire contents of the Example Scripts folder into your personal Scripts folder or the main Scripts folder for use with Script Runner. (You will have to quit Script Runner and relaunch it to make the newly-added scripts appear in the menu.) Be sure to make copies of them if you install them in your personal Scripts folder, because removing them from the Example Scripts folder would make them unavailable for installation by any other users of your machine who don’t have access to your user domain.

Script Runner is not automatically launched when you boot up under Mac OS X. To avoid having to dig it out of the AppleScript folder and launch it manually every time you start up, add it to the list of Login Items in the Login pane of System Preferences. This will cause it to launch automatically every time you start Mac OS X, as if you had put it in the Startup Items folder in the classic Mac OS. You could instead install it in the Dock and launch it when needed, but launching it at startup via Login Items is more convenient and conserves valuable Dock real estate.

Terminal application
Those familiar with Unix will take delight in knowing that Terminal is included in a standard Mac OS X install, located in the Utilities subfolder of the Applications folder. Terminal provides the Mac OS X command line interface, or CLI, familiar to Unix users.

In addition to all the other amazing things that can be done here, you can run AppleScripts from the command line. We will not go into details in this report. To learn how to do it, launch the Terminal application, type man osascript at the % prompt, and press the Return key. You will be presented with a simple manual describing the osascript command and parameters. It also refers you to manuals for two other AppleScript-related commands, osacompile and osalang. There are limitations to what can be done with the osascript command, but Apple is working on refinements to make it more usable.

The Terminal application itself is not scriptable, although there have been rumors that it will become so in future.

Apple System Profiler application
Apple System Profiler v2.6b21, in the Utilities subfolder of the Applications folder, is the latest version of this frequently-updated utility. Its dictionary is very similar to that of version 2.5.7, found in Mac OS 9.1 and the Classic environment. Changes to the Apple System Profiler dictionary are discussed below.

ColorSyncScripting scripting addition application
The dictionary of ColorSyncScripting 3.1, in the ScriptingAdditions folder in the system-level Library folder, is identical to the dictionary contained in ColorSync Extension 3.0.3 in the Extensions folder of Mac OS 9.1. (Note that the segmented version of Mac OS 9.1 made available for download in early January 2001 did not include the version 3.0.3 ColorSync Extension; this is one reason to upgrade using the Mac OS 9.1 CD that comes with Mac OS X.)

Internet Explorer application
Microsoft’s Internet Explorer 5.1b1, in the Applications folder, has a dictionary that is identical to that of Internet Explorer 5.0 in Mac OS 9.1.

Help Viewer application
Help Viewer 1.7, in the CoreServices subfolder of the System-level Library folder, has the same dictionary as Help Viewer 1.6.2 in Mac OS 9.1.

Image Capture Extension application
Image Capture Extension, bearing the tuxedo-and-bow-tie icon usually associated with the various assistants, is in the Carbon.framework bundle, buried deeply in the Frameworks folder of the System-level Library folder; it is best to locate it using Sherlock. To open its dictionary easily, use Script Editor’s Open Dictionary command, which gives you an alphabetical list of scriptable applications. It appears to be of limited interest, but an example script using it to rotate images appears in the Scripts subfolder of the Image Capture folder in the main local domain Library folder.

Mail application
Mail 1.0 is a Mac OS X-only e-mail client application, in the Applications folder. It is a bundled (or packaged) Cocoa application whose scripting dictionary is quite extensive. Support for editing mailbox content reportedly is not working in Mac OS X 10.0.

On March 24, 2001, Apple released Mail Import Scripts 1.0.5, three AppleScripts that help you import e-mail messages into Mail from a variety of third-party e-mail clients, including Netscape Communicator 4.x, Eudora 5.x, Outlook Express 5.x, and Microsoft Entourage.

Mail’s dictionary is in the form of a couple of so-called plist, or property list, files within the bundle. If you wonder what a plist-based AppleScript dictionary looks like in its raw form, Control-click on the Mail application icon and choose Show Package Contents in the contextual menu. Navigate through the Contents and Resources folders to the English.lproj folder (or the equivalent folder for your preferred language), then drag the Mail.scriptTerminology file onto the TextEdit icon. You will be looking at a plist AppleScript dictionary. (Be careful not to edit it, unless you know exactly what you are doing.)

Print Center application
Print Center 1.0, in the Utilities subfolder of the Applications folder, is where you set up your AppleTalk printers, USB printers, and LPR printers using IP, and monitor their print queues. Its dictionary appears to be a work in progress, including a Test Event command, for example. The descriptions of most of the commands say that they are sent, suggesting that the application sends events to your script, but this may not be so. In the absence of instructions or examples, I have been unable to figure out how to use most of these commands.

QuickTime Player application
The final release of QuickTime Player 5.0 was first introduced as part of Mac OS X. The revised QuickTime Player dictionary (see below) is very complete, expanding even beyond that of QuickTime Player 4.1.3, the latest version available in Mac OS 9.1. It lives in the Applications folder. Reportedly, its scripting abilities may require purchasing the Pro version (your QuickTime Player 3 license won’t work, even though it works with QuickTime Player 4; if you purchased a QuickTime Player Pro 4 license, however, it reportedly will work with version 5). A number of AppleScripts for QuickTime Player 5 are available for download.

Sherlock application
Sherlock 3.1, in the Applications folder, replaces Sherlock 3.0.2 from Mac OS 9.1. Their dictionaries are identical.

Standard Additions scripting addition
Standard Additions 1.6, in the ScriptingAdditions folder in the System-level Library folder, is new since Standard Additions 1.5.5 in Mac OS 9.1. There are several important changes in the Standard Additions dictionary.

Stuffit Expander application
StuffIt Expander 6.0.1 is included. The dictionary is identical to that in StuffIt Expander 6.0, the next most recent version released by Aladdin Systems.

A free upgrade to StuffIt Deluxe 6.0.1 is available from Aladdin Systems. The 6.0.1 upgrade is essential for users who want to compress files using StuffIt Deluxe in Mac OS X, because it fixes problems that version 6.0 had with compressing or decompressing some Mac OS X files. It comes with simple instructions to make most elements of StuffIt Deluxe run natively in the Mac OS X environment.

TextEdit application
TextEdit 1.0, in the Applications folder, is another bundled application built with the Cocoa frameworks, like Mail. It appears to be positioned as the standard text processing application for the Mac OS X environment, and it is scriptable with a reasonably useful dictionary. It is certainly a nice replacement for the Classic Mac OS SimpleText application.

URL Access Scripting scripting addition application
URL Access Scripting is version 1.0 (v3) in Mac OS X; the latest version available for Mac OS 9.1 is 2.3. Their dictionaries are identical.

Dictionary Changes
Several changes have been made to scriptable items in Mac OS X that have been updated from their Mac OS 9.1 versions.

Apple System Profiler application
One new command appears in the dictionary of Apple System Profiler v2.6b21: Pref. This command is hardly English-like; would you tell somebody to pref in polite company? This command, according to the dictionary, opens the preferences dialog of the application. The Gathers At Launch and the Preferred Report Contents properties of the Application class and the Report Contents property of the Report class take the new OSX Extensions and Frameworks contants, and there are matching OSX Extension Volumes and Framework Volumes properties. Extensions are Mac OS X kernel extensions with the .kext file extension; my installation has over 200 of them. Frameworks are header files of interest to developers, although they are also essential to the operation of many elements of Mac OS X; my installation has about 150 of them.

Finder
The dictionaries of Finder 9.1.1 and Finder 10.0 are similar at first glance, but on closer inspection there are many omissions and new features in Finder 10.0, some reflecting differences in the underlying operating system and others the fruit of an ongoing effort to simplify and rationalize the Finder’s dictionary. The difference that has the most serious consequences is the removal of the Computer command from the Finder’s dictionary to Standard Additions in Mac OS X, discussed elsewhere in this report.

Other changes are listed here:

The Restart, Shutdown and Sleep commands are missing from the Finder Basics suite, perhaps because this is a multiuser operating system and one of your machine’s users shouldn’t have that kind of control over the machine.

In the Application class of Finder Basics, the following elements are gone, as are their associated classes: Sharable Container, Sound File, Suitcase, Font Suitcase, Accessory Suitcase, Process, Application Process, Accessory Process, Container Window, Information Window, View Options Window, and Content Space. In some cases, these reflect only the fact that the element has been renamed or moved elsewhere in the dictionary. In others, the omissions reflect omitted or different functionality in the underlying operating system. In still others, I believe they reflect a long-standing desire among the designers of the Finder’s dictionary to simplify it by omitting redundant classes without limiting the ability to script the underlying functionality. The Internet Location element is renamed Internet Location File, to match the associated Internet Location File class that was already in the Files and Suitcases (now simply Files) suite. A new Finder Window element is added, which is accessible by numeric index and by ID; you can still rely on the already-existing Window element to access a window by name. Many of these omissions and changes also occur in other classes, such as the Container class, and will not be repeated in this listing.

The following properties are gone from the Application class: Largest Free Block, File Sharing, Sharing Starting Up, About This Computer, and Execution State. I believe some of these will reappear in other places. These new properties are added: Startup Disk, Trash, and Home. Only Home offers new functionality, reflecting the multiuser nature of the operating system.

The Special Folders class is omitted. It had not kept up with advances in the Path To command of the Standard Additions scripting addition, anyway, and had become redundant.

In the Finder Items suite, the Put Away command is omitted because the functionality no longer exists in the Finder. The little-used but very important Update command has acquired a new parameter, Registering Applications, which defaults to true. Somebody needs to explain this one.

The Item class has lost its Id (moved to the Finder Window class), Folder, Selected, Content Space, and Window properties, but it has gained the following new properties: Url, Icon Size, Owner, Group, Owner Privileges, Group Privileges, and Everyones Privileges.

The Sharable Container and Sharing Privileges classes are no longer available in the Containers and Folders suite.

In the Disk class, an important new property is added, Format, which gives you a long list of enumeration constants from which to choose. These include Mac OS Format, Mac OS Extended Format, and UDF Format.

In the Files (formerly Files and Suitcases) class, the Locked property is gone.

The Clipping class has a new Clipping Window property.

The Window class has a new Id property giving the unique id of a window, enabling the new by ID accessor available through the new Finder Window class. The Popup and Pulled Open properties are omitted because popup windows (the tabs along the bottom of the screen) are not available in Finder 10.0, having been replaced by the Dock with its ability to present menus from installed folders.

The Information Window class has been renamed the Inspector Window class. It has not changed, except that the parameters to the Current Panel property are different, reflecting the different way in which the Mac OS X Inspector works.

In the Type Definitions suite, there are new Icon View Options, List View Options and Column classes. These mostly encapsulate already-existing properties, such as the Arrangement property of the Icon View Options class. I am excited about one new property, the Index property of the new Column class, because it is not marked r/o for read-only. This suggests that I may be able to change the order of columns in list view windows via script, which will allow me to move the Version column to second position, next to the Name column, where I want it in all my list windows. But I can’t make this work in Finder 10.0.

In sum, there is a lot to learn about scripting the new Finder. The process will be difficult for the time being, because the temptation to blame your failures on system bugs will be unusually hard to resist.

QuickTime Player application
The Standard Suite of QuickTime Player 5.0 has new Data Size and Delete commands. The QuickTime Player Suite is greatly expanded, adding five new classes (Chapter, Display, Frame, Stream, and Text Frame) and nine new commands (Add, Clear, Copy, Cut, Open Image Sequence, Paste, Redo, Trim, and Undo). The Open Location command has a new Position parameter. The Present command has a new Mode property allowing specification of Normal or Slide Show, and a new Display parameter allowing specification of the monitor on which to present a movie. The Application class has three new properties (Clipboard, Ignore Auto Play, and Ignore Auto Present), and the QuickTime Connection Speed property enumerates several new constants. The Display class brings new power to the ability to use AppleScript to understand what monitors are available; for example, on my new PowerBook G4 Titanium, ‘dimensions of display 1’ returns ‘{1152,768}’. The Favorite class adds several elements and properties, including the Category of the favorite. The Movie class adds 21 new properties; the Track class, 20 too many to name them all here.

Standard Additions scripting addition

Standard Additions 1.6 in the Mac OS X environment sports a few dictionary changes since Standard Additions 1.5.5. See Testing Whether AppleScript 1.6 is Installed for information about the new System Attribute command. In addition, the Choose Application command’s optional Application Label parameter is replaced by With Title. Typing ‘application label’ will not compile to ‘with title’; it won’t compile at all. The two parameters serve somewhat different purposes, now that Choose Application does not allow choosing a remote application to link to, but only a local application. Some of the commands now assign plain text as the type of properties that were formerly typed as string.

The Path To command has been enhanced for Mac OS X to deal with multiple domains. There may, for example, be Scripting Additions folders in several individual users’ Home folders, and in the main Library folder at the root level of the Mac OS X disk, and in the Library folder in the network domain, in addition to the system-level Scripting Additions folder. To accommodate multiple domains, the Path To command has been given a new From parameter that lets you specify whether to look for the desired special folder in the ‘System domain’, ‘local domain’, ‘network domain’, or ‘user domain’. For example, ‘path to scripting additions from user domain’ returns alias :Users::Library:ScriptingAdditions:, where is the user currently logged in, and ‘path to scripting additions from local domain’ returns alias :Library:ScriptingAdditions:. The indicated result is returned even if the special folder does not currently exist in the specified domain, and the specified folder is created, as has always been the case but only if the user has privileges to change that domain. The default domain when the From parameter is omitted varies depending on the special folder you designate, based on Apple’s sense of which domain is appropriate for that special folder; for example, for scripting additions the default is the System domain, but for preferences it is the user domain. Varying the default domain, instead of having an easy-to-remember fixed default domain for all special folders, was a bold design decision on Apple’s part. Some of the defaults may be open to debate. For example, the Scripts Folder and Folder Action Scripts Folder location selectors default to the System domain, but there are no such folders there in the current release of Mac OS X. Since users do not have write access to the System domain, omitting the From parameter for those locations guarantees a run-time error, as described below. Most scripters may find it easiest to use the From parameter in all cases, in order to avoid having to look up the default.

You can get unexpected results if you don’t understand just how the Path To command works in Mac OS X. For example, if you run ‘path to AppleScript’ in Script Editor, it returns an alias to the Script Editor application, but this is only because it is, in effect, interpreting the command to mean ‘path to current application’. The same command would return a different result if run from another editor, and it returns the path to itself if run as an applet. Also, if a requested special folder does not exist in the domain in issue, the command will generate an error if the current user lacks write permission for the domain in issue, instead of simply creating the folder as it does in Mac OS 9.1 and earlier. For example, ‘path to scripts folder’ now returns error number -5000 (known to programmers as afpAccessDenied), because the Path To command defaults to the System domain, which does not contain a Scripts folder and does not let any user create one. The error message is accurate (Folder does not exist, and you don’t have access privileges to create it.). In this case, you have to be careful to specify the desired domain; ‘path to scripts folder from user domain’, for example, works correctly, creating the folder if it does not exist, instead of generating an error. It may also be the case (I haven’t tested this) that when the user is logged in as administrator, a script will be able to get the path to a nonexistent special folder from the local domain, while attempting to do so would cause an error if the user is logged in as a normal user without write access to the local domain. The access privileges issue will trip up older scripts that previously worked correctly, in cases where a special folder does not exist in a domain to which the current user lacks write access, and it will undoubtedly trip up new scripts that are not written defensively to test for this issue. Such is the price of progress, for the multiuser capabilities of Mac OS X are a definite advance.

In general, the Mac OS X Standard Additions dictionary retains the classic Mac OS special folder constants for use with the Path To command, but scripts directed at Mac OS X will generate errors if they use constants that are meaningful only in the Classic environment or Mac OS 9.1. This is one of the reasons why you are advised to test your environment before executing script commands that differ as between environments.

Apple’s new AppleScript 10.0 Overview gives the following examples of supported Path To locations, some of which must be given as four-character codes in this version of Mac OS X: preferences folder, help folder, desktop pictures folder, At Ease documents folder (At Ease is an anachronism; it refers to the Mac OS X Documents folder), At Ease applications folder (the Mac OS X Applications folder), ‘ssnd’ (Sounds folder), 'favs (Favorites folder), ‘dlib’ (Library folder), ‘cuser’ (the current user’s Home folder), temporary items folder, ‘usrs’ (Users folder), ‘root’ (the System folder, current user’s folder, or Network folder, depending on domain), ‘sdat’ (Shared documents folder), scripts folder (the folder where Script Runner gets its menu items). In general, for the developers among you, you can use any four-character string that is a FindFolder selector as declared in the Folders.h header file. 9/22/01

The Scriptable Finder

In a sense, the Finder has undergone its most extensive revision since the Macintosh was first released, because it now has to deal with a radically changed infrastructure. Although its dictionary remains very familiar, there are many changes, some of its features are not yet implemented or don’t work correctly, and other features may change before too long. Even with the limitations in its current scripting implementation, the Finder remains the enormously powerful tool that it has been since it became scriptable some years ago. For an example of its power, check out the Build web page example script in the Scripts subfolder of the Image Capture folder in the main Library folder.

In considering the many changes to the Finder’s dictionary, do not be misled by the fact that the Finder in the Classic environment is still Finder 9.1.1, while the Finder in the Mac OS X environment is Finder 10.0. If you boot into Mac OS 9.1 directly, you will see the familiar Finder 9.1.1 dictionary. But if you boot into Mac OS X and attempt to examine the Finder 9.1.1 dictionary in the Classic environment, you will discover that it has magically transmogrified into the Finder 10.0 dictionary. (You must use the Classic Script Editor to do this, because the Mac OS 9.1 Finder is dimmed and can’t be selected if you use the Mac OS X Script Editor’s Browse button in an attempt to open its dictionary.) In other words, Finder scripting when booted into Mac OS X uses the same new terminology, no matter which environment your script addresses. When you boot into Mac OS X, you boot into a world where many low-level system hardware and operating system features are controlled by the new Mac OS X kernel, and so the Finder as well as other system-level software must depend upon them in either environment.

I have not exhaustively tested Finder scripting in Mac OS X, but I have found an oddity or two, and many others are already being reported on the mailing lists. For example, the statement ‘make new file at desktop with properties {name:Test}’ creates a SimpleText file, although SimpleText is not included in the standard Mac OS X installation. When you double-click the resulting file for the first time, SimpleText is launched in the Classic environment. Although this may be appropriate to preserve backward compatibility, I would prefer to see a scriptable RTF Mac OS X application like TextEdit become the new standard for text files. Having to launch the Classic environment to read such a file is a nuisance, and what if the user did not install the Classic environment? (A Carbonized version of SimpleText does appear on the Developer Tools CD, and it runs in the Mac OS X environment; however, it was written as a demonstration of Carbon techniques for developers, not as a standard text editor for Mac OS X. It is not as competent a text editor as TextEdit.) There also appear to be unimplemented or buggy commands in the Finder, still. For example, I can’t make the Select command select a specified item, getting error number -10000 if the item exists but the correct error if it does not exist.

Bill_Cheeseman · September 26, 2001, 2:23am

FIXED BUGS

Many AppleScript bugs have been fixed, as is usual with new releases of the Mac OS. These are the fixes most likely to benefit you (fixes to a few very rare issues are omitted from this list).

The Read/Write commands in Standard Additions 1.5.5 had disabling problems, including when writing to lists and reading files using delimiters. Almost all of these are fixed in Standard Additions 1.6.

They correctly read back binary data that was originally written As List or As Record and contained nested lists or records.
They correctly read back successive lists or records.
They read the remaining bytes in a file when requested to read more bytes than exist in the rest of the file, without generating an error. The next Read will generate a proper end of file error.
They work correctly on files larger than 2 Gigabytes, using double integers rather than integers as the type of all parameters and results relating to file position. You will normally see these as real numbers.

The Read/Write commands also have what might better be called enhanced behaviors than bugs, outlined by Chris Nebel:

They allow reading a file with the Using Delimiter option set to a list of any number of single-character delimiter strings, rather than only one or two delimiter strings, as before (although the comment in the dictionary still refers to the two-character limit). Apple’s Chris Nebel pointed out on the AppleScript-Users mailing list that single-character means single-byte, so that two-byte charcters in some language systems cannot be used as delimiters, and that additional characters in any one delimiter string beyond the first character will be ignored.
They allow omission of the As parameter from Using Delimiter, in which case As Text will be assumed. This is also true if you use Before or Until. Formerly, you always had to use the As parameter with Using Delimiter.
They allow the use of positioning parameters such as From and To when reading a file As List, unless it is being read as a binary list without delimiters (where the list data itself specifies how much to read). However, a bug causes problems when reading a text file As List. Formerly, you could not use positioning parameters with As List, and the command always read from the current position to the end of the file.

See New Bugs in Mac OS X for a discussion of two new bugs in the Read/Write commands.

Cancelling the Where is application dialog when compiling or loading a script no longer causes it to reappear repeatedly, as it did in AppleScript 1.4.3 and 1.5.5.

A running script now responds to more than one successive incoming event. It reportedly did not in AppleScript 1.4.3 and 1.5.5.

A bug has been fixed that could in rare cases cause an applet in AppleScript 1.4.3 and later to fail to retain the value of a variable or to think the variable is undefined, especially with applets using global variables and idle handlers and making heavy use of memory after running for a long time.

The statement ‘strings of ’ now returns error number -1728, can’t get every string of , instead of returning an empty list as it always has.

The statement ‘text of ’ now returns the string itself, instead of returning an empty list as it always has.

The statement ‘some of ’ now returns error number -1728, can’t get some of , instead of returning the entire record as it always has.

A null string will appear in the Results window and Event Log as a null character between quotes (it is visible in some fonts), as it did in AppleScript 1.0 through 1.1.2, and it will copy and paste in correct, compilable form. In AppleScript 1.3 through 1.5.5 it appeared in various other forms and in some cases would not compile after being pasted into a script.

A script compiled to target an application in the Mac OS X environment can be opened in the Classic environment. This was not true in Mac OS X Public Beta in the case of applications that have counterparts in both environments.

A script targeting a bundled (or packaged) application in the Mac OS X environment, such as Mail, will successfully control that application when run in the Classic environment.

AppleScript 1.6 will now load bundled (or packaged) scripting additions. To run in Classic or on Mac OS 9.1, the bundle must include a top-level alias file that points to the Mac OS 9 (non-Carbonized) scripting addition file contained in the bundle (or package).

The Mac OS X version of Script Editor 1.6 can now read the dictionaries of bundled (or packaged) applications. The Classic version of Script Editor 1.6 still cannot.

In Mac OS 9.1, none of the commands in Standard Additions worked if the new Security items in the Extensions folder were disabled. This bug bit many users who routinely disabled the Security items because they did not use the Keychain and felt secure enough without the extensions. In both the Classic environment of Mac OS X and the new 1.6 release of Standard Additions for Mac OS 9.1, only the Mount Volume command in Standard Additions requires the Security items.

Old-style control panels, like the newer control panel applications, can now be launched by directing a Tell command at them (even if they are not scriptable).

The many problems with Unicode text manipulation in Mac OS 9.1 are, for the most part, fixed in AppleScript 1.6. Any operation (well, almost any) that can be performed on a string value can be performed on a Unicode text value, such as coercion to and from string and styled text, coercion to and from numeric values, the Length property, the Count command, string concatenation, the Character, Word and Paragraph elements for use with the indexed, special index and range keyforms, and magnitude and equality comparisons.

The Random Number command in Standard Additions has been improved to make the generated numbers more evenly distributed and less predictable. Chris Nebel has indicated that there are nevertheless problems in 1.5.5 and 1.6 with random integers coming out with different frequencies. The endpoints (in this case, 1 and 56) tend to turn up out of proportion to the others. 9/22/01

Bill_Cheeseman · September 26, 2001, 2:29am

NEW BUGS IN MAC OS X
Running Mac OS X Classic for the first time places CarbonLib 1.2 in the Classic environment’s Extensions folder, if an older version is found (the Mac OS 9.1 disk that comes with Mac OS X installs CarbonLib 1.1.1). CarbonLib 1.2 is not the finished version of CarbonLib; CarbonLib 1.2.5 was already already available separately from Apple, and CarbonLib 1.3.1 became available shortly later. Each new version of CarbonLib has brought many bug fixes and new features, and this trend can be expected to continue. It is unclear what changes affect AppleScript and the Script Editor, but there are probably some that do, and updating to the latest version is therefore highly recommended. Mac OS 9.2.1 includes CarbonLib 1.4, and CarbonLib 1.4 can be downloaded separately for installation on earlier versions of the Mac OS going back to and including Mac OS 8.6. 9/22/01

Apple has published Tech Info Library article 106302, Mac OS 9.1: Conflict Between CarbonLib 1.3.1 and AppleScript. It describes a conflict between AppleScript and CarbonLib 1.3.1 in Mac OS 9.1 that can freeze the computer, with suggested solutions. The solution now, of course, is to upgrade to Mac OS 9.2.1, or at least to install CarbonLib 1.4. 9/22/01

I experienced difficulty seeing the left pane of the dictionary window in Script Editor 1.6 after enlarging it and choosing Set Default Window Size from the File menu. Resizing it, or even just clicking on the resize control, seems to cure the problem for a particular dictionary.

The Read/Write commands of Standard Additions exhibit two known new bugs:

Using the As List and Using Delimiter parameters in the same command doesn’t work right, incorrectly embedding each list item in a sublist. In this case, use As Text, instead.
Using the As parameter with Before or Until without a Using Delimiter parameter will generate an error or return garbage. Instead, read the file without the As parameter and coerce the result afterwards.

Both of these bugs will be fixed in the next release.

Magnitude comparisons with Unicode text do not honor the Considering Case condition correctly.

Marco Piovanelli reported that AppleScript 1.6 has broken the ability to coerce Unicode text to normal strings. A simple coercion like ‘<> as string’ generates a runtime error, in both the Classic and Mac OS X environments. I discovered that, for an easy workaround, you can use ‘<> as international text’. Apple’s Chris Espinosa later wrote, the utxt → **** handler is broken for typeChar, and has been since 1.5.5. The good news is that typeStyledText works, so I guess a workaround for now would be to coerce the unicode to typeStyledText, then coerce the result to typeChar. 9/22/01

Steven Angier reported (and this was confirmed by Apple’s Chris Nebel) that there is a crashing bug in the Standard Additions choose file name command under Mac OS 10.0.4. Supplying an empty default name string will crash the current script editor or script application when the command is executed. 9/25/01

Chris Espinosa of Apple has remarked upon a subtle point of Finder usage that might be seen as a bug. When the Finder returns an empty value collective Get Data operation (anything with a plural anywhere in the direct object, such as your ‘name of folders of myFolder’), it doesn’t return an empty list, it returns an empty record. Which looks and prints and smells like an empty list, and compares correctly to an empty list, but can’t do list-like things, like having its end set. [‘if theClients = {} then set theClients to {}’] is unfortunately the correct workaround, as there’s no way to specify an empty record in AppleScript itself. 9/22/01

Apple’s Chris Nebel confirmed that the Finder in Mac OS X 10.0 doesn’t understand file references. However, alias references and long-hand Finder object specifiers both work fine. 9/22/01

Chris Nebel confirmed that [c]ounting paragraphs and getting individual ones (e.g. paragraph 42 of …) does the right thing with cr, lf, or crlf line endings, but getting a range of paragraphs (e.g. paragraphs of …, paragraphs 2 thru 17 of …) messes up with crlf line endings. In the latter case, the effect is to see a spurious empty paragraph between every real paragraph in the returned result. 9/22/01

AppleScript 1.6 introduces a known problem with using the mount volume command to mount volumes hosted on certain kinds of servers, especially Windows 2000 machines. This problem will be addressed in a future version of AppleScript. 9/22/01

Bill_Cheeseman · June 24, 2006, 2:36am

INFORMATION FOR DEVELOPERS
If you are a developer, you will want to install the Mac OS X Developer Tools that ship with every copy of Mac OS X 10.0. These install a large number of tools and documents of interest almost exclusively to developers, including some relating to AppleScript. The AppleScript features of Developer Tools are described briefly here.

After the Developer Tools are installed, your Mac OS X startup volume contains a new folder, Developer. The Developer folder contains many subfolders.

The Applications subfolder includes, in the Extras folder, two scriptable applications, Sketch (a bundled Cocoa drawing application) and WorldText 1.1. As noted above, WorldText is scriptable almost by accident as a result of the development environment used to create it. Two other applications installed by Developer Tools are scriptable, PEFViewer (another of those accidentally scriptable applications) and Interface Builder. Interface Builder is the Cocoa visual user interface builder application; it is quite interesting to find that it is scriptable.

The Documents subfolder contains a dozen folders with documentation for various aspects of Mac OS X development. The documentation remains a mixed bag of old documents, revised documents and new documents, reflecting the perfectly understandable priority that Apple attached to getting the product out the door on time. We will not attempt to list everything related to AppleScript that can be found here. Examples include the interapplicationcomm folder in the Carbon folder, which includes the old AppleScript 1.3.4 Language Guide in HTML format and other material of use in Carbon-based AppleScript development, and the ProgrammingTopics and TasksAndConcepts folders in the Cocoa folder and other matter of use in Cocoa-based AppleScript development. The most interesting item for scripters may be the ReleaseNotes folder, which includes, among other things, a small file called AppleScript.html, which contains some Release Notes for AppleScript 1.6 in the Mac OS X environment. This contains pointers to other AppleScript developer information, a summary of how to write scripting additions for Mac OS X (including some information which I don’t believe has been systematically made available previously), and a short list of known bugs in AppleScript 1.6.

The Examples subfolder includes source code for some scriptable applications, including the scriptable TextEdit and Sketch applications built with the Cocoa frameworks.

In the months since the release of Mac OS X 10.0, new documentation for developers interested in AppleScript has trickled out of Apple, including the following:

Technical Q&A QA1070, Loading Scripting Additions without initializing AppleScript in Mac OS X.

Revised Technical Note TN1164, Native Scripting Additions. It now includes additional information needed by developers to write native scripting additions for Mac OS X information that was previously available only to those who knew whom to ask or watched the mailing lists closely.

Technical Note TN2022, The Death of typeFSSpec: moving along to typeFileURL. It explains for Mac OS X developers how to pass references to files that have not yet been created. This issue has had an impact on developers of recordable Mac OS X applications.

Technical Q&A QA1018, Using AppleScript to send an email with an attachment. This developer Q&A item contains the text of a complete AppleScript for using the Mac OS X Mail program to allow the user to choose a text file that will be attached to an outgoing e-mail message.
9/22/01