First, a little back story. Packages were actually introduced in OS 9 as a method by which a folder could masquerade as an application. Double-click on this faux folder, and it launched like an application -- or rather, like an alias of an application. The reason it was useful and geek-cool was that the package (which really was a folder, even though it wasn't) contained the real program along with various support files that would normally get scattered hither and yon in the nether regions of your System Folder.

Fast forward to today. With OS X, virtually all applications are packages, except they're properly referred to as "bundles." Let's unwrap a typical Bundle and see what salutes.

Nitty Gritty Bundle Spelunk

According to Apple's preliminary "Inside Mac OS X: System Overview" developer's document: "Typically the Finder displays a bundle directory to users as a file to avoid unwarranted tampering with the bundle's contents." From the average user's point of view, then, the bundle acts like an OS 9 package -- double-click and off the application goes.

Nowadays, however, it's a lot easier to see what that stealthy folder is hiding. As an example, let's take a look at the venerable Key Caps program, a revamped version of which should be in your OS X Applications folder (just click on the "Apps" button in a Finder window). Click once on Key Caps while in Columns view and another column opens up to inform you, along with a sexy 128x128-pixel, THX-enabled, Smell-o-Vision icon, that this is an Application.

If you instead Control-click on Key Caps, a contextual menu allows you to select "Show Package Contents" -- another Finder window pops open and there's a folder called, appropriately enough, "Contents." Inside you'll find a few items typical to OS X bundles:

Info.plist
MacOS/
PkgInfo
Resources/
version.plist

In taking at look at these, we'll cover the basics for each, although space constraints necessitate a bit of simplification. See the various links for more detailed info. Also, keep in mind that while all applications are bundles, not all bundles are applications: there are a few sub-species of bundle we won't cover here.

(Quoted passages in the section below are from the "Inside Mac OS X: System Overview" document mentioned earlier.)

Skipping the "MacOS" and "Resources" directories for the moment, let's look at the files on this level.

Info.plist is the information property list, an XML-formatted text file that contains "attributes such as the name of the main executable for the bundle, version information, type and creator codes, application and document icons, and other meta data." Sometimes you'll see a variation on this where different platforms need their own lists, so "Info.plist" will be replaced by multiple files such as "Info-macos.plist" and "Info-macosclassic.plist" -- otherwise, the file takes care of all platforms.

Those .plist files, by the way, can be viewed -- just drag them to TextEdit. Bonus OS X tip: to force an application to open a document it wouldn't normally, due to the Finder database, hold down Command and Option as you drag. Now it will highlight the application icon and open.

While you're trying to guess what "PkgInfo" stands for, you should know that it merely stores the bundle's type and creator codes. As the System Overview points out, this is redundant information (Info.plist has it, too). Basically, though, it speeds up the Desktop trying to display what files are. If it had to wade through the whole Info.plist looking for those codes, it would slow things down tremendously. Essentially, PkgInfo is a cache, like your web browser has. version.plist performs a similar function, but contains application version strings (number, release status, etc.).

One of the interesting topics that this caching illuminates is the differences in the Desktop information databases between OS 9 and OS X. In OS 9, there is a desktop file for each volume on the system, and it lists all the files and folders for that volume. "When the system is booted, the Finder builds these databases and, thereafter, dynamically updates them as files and directories are added, changed, and removed." OS X, on the other hand, is a multi-user OS from the get-go, which means:

"...the Finder maintains an application database for each user who has an account (local or network) on a system. This database contains information about all the applications the Desktop has encountered for that user and includes information about the document types understood by each application. The Desktop extracts this information from the information property lists of applications..."

In other words, the database is built as a user uses the machine, and will be different for each user. When an application is first launched by the Finder, it grabs the info it needs from Info.plist, updates its databases, and then caches certain data for quickness later.

Back to Key Caps. Inside the MacOS/ folder, you'll find, in an Escher-esque, Mobius-strip sort of paradigm, a document called "Key Caps." This is the executable code -- the program that launches when you double-click on the sexy icon. What you'll often find in Carbonized bundles (those that run on both OS 9 and X) are two folders, "MacOS" and "MacOSClassic."

The last item in our Key Caps bundle is the Resources/ directory. Inside are a series of language-specific ".lproj" folders and two other files:

Dutch.lproj/
English.lproj/
French.lproj/
German.lproj/
Italian.lproj/
Japanese.lproj/
Key Caps.rsrc
KeyCaps.icns
Spanish.lproj/

Each of the .lproj folders contains two files: "InfoPlist.strings" and "Localized.rsrc".

"Resources can be localized or nonlocalized -- that is, suitable for all localizations. Each set of localized resources goes into its own directory in the bundle [with the ".lproj" extension]. ... Nonlocalized resources are put in the level directly above the .lproj directories as there need be only one version of these files."

Normally, the ".icns" file will contain the application's sexy icon. This file can be any of several formats, so you may see others here. You can view .icns files with the Preview application (included in the Applications folder). While Key Caps only has one, there may be several different .icns in the Resource/ directory; Internet Explorer, for example, has a bunch. One series is "bzy0.icns," "bzy1.icns", etc. -- these are the various stages of a file being downloaded, as it might show up in a Finder window.

Whither ResEdit?

True to the spirit of Mac hacking in ages past, all those icons are modifiable. Check out ResExcellence's OS X page for tips on that and more.

If this all sounds familiar, it probably means you're familiar with ResEdit and the resource and data forks of classic Mac OS. And you'd be right in assuming this is very similar. And in fact, with a bit of tweaking, a developer could still do the same thing (i.e., store all resources in a single file) in OS X. Apple, however, "strongly recommends" adopting the new model:

"One consideration behind this is the emerging use of XML as a way to specify resources. Carbon has an XML-based runtime that tools such as Interface Builder use to export user interfaces as XML.

"As with applications, documents on Mac OS X should have their resources put in the data fork. The reasons for this are the same as the reasons for having application resources in the data fork. It makes it possible to exchange these documents, without loss of resource data, between Macintosh and non-Macintosh systems, including most Web servers."

Meanwhile, .rsrc files at the non-localized level of Key Caps.rsrc store various resources specific to the application and generic enough to not require localization. The latter would be included in the aptly named "Localized.rsrc" files under each .lproj folder.

Keep in mind, too, that it isn't just the icons, strings, and other jetsam from the old resource-fork days that can be in a bundle. Keeping an application's wanton file-spewing in one place, and out of my freakin' System Folder, is a Good Thing. Install any monopolistic company's product on OS 9, and you'll see what I mean. Then check out Internet Explorer's bundle on OS X Public Beta, specifically the MacOS/ directory there.

A Terminal Approach

Another interesting sideline to all this is what happens when you approach a bundle from the a Terminal window. Indeed, the bundle will show up as a directory. Drill inside, and you'll see a "Contents" folder. This is actually the proper hierarchy of a bundle, and the contents of "Contents" are what show up when you Control-click "Show Package Contents." (Makes sense, eh?)

Developing a Taste for Bundles

Developers should already be aware of the "Core Foundation Bundle Services" publication in the Apple Developer Connection (ADC). Those interested in even more geeky details should definitely explore the "Bundle Concepts." For your final edification, here are the "Benefits of Using Bundles" from that section:

• A single application can run on both Mac OS 8 and Mac OS X.
• A single application can support multiple chip architectures (PowerPC, x86), library architectures (CFM/MachO), and other special executables (for example, optimized libraries for AltiVec).
• A single application can include support for multiple languages (localizations). Applications can also add new language support or remove unwanted language support simply by adding or removing resources.
• Applications can reside on many different volume formats, including multiple fork formats like HFS, HFS+, and AFP, and single-fork formats like UFS, SMB, and NFS.
• An application can run directly from a server. No special shared libraries, extensions, and resources need to be installed on the local system.
• Because an application package both includes and hides all the executables, resources, libraries, help files, required plug-ins, and other elements necessary for execution, users cannot accidentally break an application by renaming it, moving it, or otherwise manipulating it in the Finder.
• Shared libraries and plug-ins enjoy the same advantages as applications. All necessary resources and localizations are included.
• Application installation, relocation, and removal is accomplished simply through drag and drop.
• Help files and other important resources can be indexed and accessed through Sherlock.

And now, the wrap up...

And so, now that we've wrapped up bundles (sorry, couldn't resist), I'd like to invite the MacSlash readers to email me with Mac OS X story ideas for future columns. We've got some lined up already, but your feedback is always welcome. See you next time!