Written April 3, 99 by Thomas Tempelmann,
Updated April 15, 99: Added APPD to the list of possible app types.
All the information herein was found by myself using reverse engineering, testing (probing), looking at public documentation from Apple and others and by cachting some word-of-mouth.
Apple did not provide the information, Apple will not support the information, and the validity of this information is subject to change at any moment (that means: future Mac OS versions as well as foreign File Systems might behave differently).
There is, however, some information that you or I may get from Apple and that we're not allowed to publish, because Apple wants to keep it confidentially. When in doubt, contact Apple's developer support and ask for the information you need.
If the user opens (double clicks) a document (not an application) in the Finder, the Finder uses a complex algorithm to find the application that is to be launched in order to open the document.
Generally, the idea on the Macintosh is that every document has both a fiile type and a creator information (both are stored as 4 Byte values, usually using 4 characters to make it easy to read). While the file type is helping to identify the format of the file's contents (like 'TEXT' for plain text, 'PICT' for Mac OS type pictures, 'APPL' for applications), the creator identifies the application that created a document and thus is the one that is usually also the best one to later open and read it again.
For instance, you'll most likely have an application called "SimpleText" on your computer. Its type is 'APPL' (because it is a directly executable program) and its creator is 'ttxt' (this one has been reserved by Apple). If you create a text file with SimpleText, the file will get the type 'TEXT' and the creator 'ttxt' (SimpleText assigns it, so it is all under control of the application). This tuple of type and creator is then used to:
The first case, the icons, are not subject of this essay. You can find more about it at Apple's web size and, if you look for more internals about it, at my web site.
Let's now focus on the Finder's task to find the application with a certain creator code.
In the ideal case, there's exactly one application for each creator on the computer and no matter how the Finder finds it, it'll eventually get to it and launch it.
However, it often happens that there's multiple instances of applications with the same creator accessible to a computer. If they are different versions, then the results become quite random: Depending on several circumstances, like the creator being on a server volume or not, the app or document being on a ISO 9660 CD-ROM without a Desktop Database on it, or simply the location of the document volume on a Mac with multiple hard disk partitions, different applications with the same creator code might be located by the Finder. This document explains these rules.
Be aware that each application must have a unique creator code in order to make this technique work properly. If you release a self-written application to the world outside of your home, then you should register your own code with Apple's central database. This database has only one purpose: To make sure that no two different programs use the same creator. Registering is very easy: All you have to do is think of a 4-character code and then use a Web Browser to go to Apple's Creator Registration Site and check if it is still unused. If not, try a different code. Then register it. This all is done in a few minutes.
In most cases, the Finder relies on the Desktop Database for finding applications. This DTDB is a set of one or two hidden files in the root directory of (almost) each volume. Generally, any HFS (and HFS+) formatted volume has such a DTDB, as well as most server volumes. Same for most HFS-formatted CDs. Other disks may or may not have such a DTDB, including ISO 9660, UDF, PC DOS floppies. How this affects the Finder's ability to find an app is described below.
The DTDB keeps track of the following information from all applications on a volume:
The DTDB is created and maintained usually by the Finder only, but is accessible to other applications, too. If an application other than the Finder deletes or even duplicates an application without complying to some rules (such as clearing the hasBeenInited flag in its fdFlags), the DTDB may get out of sync with the actual set of applications present on a volume. This is when the Desktop Database needs to be rebuilt or fixed with tools like Save A BNDL.
If you want to have a closer look at the contents of the DTDB you can download my Desktop DB Diver or read my insights into the DTDB creation.
Each time a copy of an application is created on a volume, it is also registered as an individual item in the DTDB. That means that when you'd look up the DTDB for applications of a given creator code (using PBDTGetAPPL), then you can get a list of all those applications by indexing, starting at 1.
One of these apps is always the tagged one. Usually an application gets tagged by being the last one added to the list for a specific creator code. The tagged app can be inquired by calling PBDTGetAPPL with an index of 0.
This process is also documented in Apple's Technical Q&A, TB19.
Each time the Finder sees a file that has the hasBeenInited flag cleared in its directory entry, the Finder looks into the file's resource and assembles some data out of it, including the BNDL resource and the file's creator code, and add this information to the Desktop Database using calls like PBDTAddAPPL and PBDTAddIcon. The hasBeenInited flag is cleared each time a new file is created (including creating a copy of a file).
When the Finder deletes files (usually from the Trash), then it removes any apps, that are deleted in this process, from the DTDB using PBDTRemoveAPPL.
Note that there's no way to remove or update Icons from the DTDB, so once an Icon has been associated with a document, the icon does not disappear for those docs even if the creator application has been removed completely from your computer.Also, if you install a new version of an application that has different icons for its documents, those icons might not get updated unless you force a rebuild of the Desktop Database (by holding Command and Options keys down when the Finder loads at boot time, for example).
TB42 - Finder Icon Positioning and File Initialization
OPS 03 - Desktop Using Icons from Old Versions of Applications
TB 520 - Desktop Manager Q&As
TB 535 - Finder Q&As
Inside Mac - Toolbox: Creating a Bundle Resource
In the next chapter I'll explain how the Finder performs a search for an application with a specific creator code.
If, however, the Finder does not find any suitable application, then there's still several other solutions that provide a backup:
Now let's get to the Finder's task of locating the application to launch when the user opens a document. The goal of the Finder is to find an application with the same creator code as the one of the document.
The following list is what the Finder does to locate the application. If one of them succeeds, the rest of them is not processed any more, of course.
There's two loops:
Note: The above algorithm is available as C code in my LaunchLib (see FindApplicationByCreator).
That's all I know so far.
If you have more information, corrections or questions, please contact me at