|Home » Learning Curve
Creator Codes v UTIs
Something's gotta give?
Not quite two weeks since Apple's Mac OS X 10.6 Snow Leopard was released and although almost all reports are laudatory a few are not. Matt Neuburg of TidBITS noticed something about the new launch services that threw him for a loop - so much so that his boss Adam Engst submitted his article link to Slashdot.
The gist of it is Apple are now ignoring so-called 'creator codes'. Wikipedia explains.
A creator code is a mechanism introduced in pre-Mac OS X versions of the Macintosh operating system to link a data file to the application program which created it in a manner similar to file extensions in other operating systems.
The key difference between extensions and Apple's system is file type and file ownership bindings are kept fully distinct. This allows files of the same type to be written by different applications and freely opened by any application but when double-clicked will open the original application that created them.
This distinction is lost with the extensions approach.
Neuburg explains. Sort of.
The venerable Mac way of binding a document to an application is the creator code, a four letter value unique to an application, attached as metadata to a document.
Looking on the Desktop of my Mac OS 9 machine I see two ordinary plain text files; one belongs to SimpleText (creator code 'ttxt') and the other to BBEdit (creator code 'R*ch').
Neuburg obviously wants to lay the blame on Unix - the system that saved Apple from Chapter 11 some ten years ago - but things aren't that simple. Apple deliberately came out with a new - and some would say brilliant - system to supersede creator codes over four years ago. It's called the uniform type identifier. Wikipedia again.
Added in Apple's Mac OS X 10.4 operating system, UTIs are used to identify the type of files and folders, clipboard data, bundles, aliases and symlinks, and streaming data.
Mac OS X's desktop search technology Spotlight uses UTIs to categorise documents.
One of the primary design goals was to eliminate the ambiguities and problems associated with inferring a file's content from its MIME type, filename extension, or type or creator code.
Obviously some divergent and conflicting stories here.
A creator code - or the equivalent - can distinguish between an app that can handle a certain file type and 'the' app that the user wants to have handle the file type by default. Creator codes don't have to apply to the actual application that created the file - think of them instead as an indication of the 'default editor'. An example: users might prefer to have Preview open image files by default because Photoshop/GIMP take too long to just get a glimpse of a file.
So far so good.
But the creator code system in use since the 'pre-Mac OS X days' isn't particularly scalable, user-friendly, or impervious to collision risks. Apple still have a page online where software houses can register creator codes but few software houses bother. The default creator code for Cocoa applications is '????' which means nothing at all. And most apps come bundled this way.
The total number of available creator codes 2^32 or 4294967296 but in practice it's a lot less because (as seen above) Apple themselves lay claim to a huge subset. One may certainly ask what Apple intended to do with a couple of billion creator codes; one may further ask how fast two billion creator codes are going to run out; but this isn't about every last software product in existence - it's about every planned software product.
How many IPs are available on the Internet? How many are still not taken? Why do the doyens of the Internet warn that the IPs are going to run out in the next year? Whatever: it's not a particularly well dimensioned system.
Uniform type identifiers are another matter altogether.
Uniform Type Identifiers
Uniform type identifiers have been around for over four years now. They were introduced to supersede creator codes and remedy their shortcomings. And it's a good design. Wikipedia.
UTIs use a reverse DNS structure. UTIs support multiple inheritance, allowing multimedia files to be identified as not as single type (as in MIME) but as all possible types; an identifier can inherit from public.audio, public.image, public.text, public.video, and so forth.
UTIs are stored as Core Foundation strings; allowable characters are A-Z, a-z, 0-9, '-', '.', and all Unicode characters above U+007F.
Some examples provided by Apple.
UTIs are placed in a hierarchy so systems can easily deduce what type of files they're dealing with. An example from the Apple article.
Should the system not find an adequate application for 'public.mpeg' it might try finding something for 'public.movie' instead and barring that then try 'public.audiovisual-content' and so forth. TextEdit is more or less the 'public.data' editor today just as the text editor on SunOS/Solaris has functioned. And so forth.
Apple have also been adding UTI descriptions to their Info.plist files for some time. Here's part of Preview's.
The UTI com.adobe.pdf is mentioned; Preview lays claim to being default as well as an editor for the type. The system can not only suggest Preview as a way to view files of this type but also hopefully activate Preview on double-clicks. Other applications can still operate on files of this type but ceteris paribus a double-click should open Preview instead.
The system 'can' rely on file extensions but it's wide open for exploitation by extended attributes. All that's been eliminated now are the creator codes. Starting now all software titles will have to provide another way - be it a file extension or a more elaborate Info.plist with additional metadata stored as XAs - to tell the world who they are.
Neuburg drops the accusation Apple are 'stealing' files several times in his article.
When you create a text document with BBEdit, BBEdit assigns it the 'R*ch' creator code but nevertheless it belongs by default to TextEdit. It has TextEdit's icon and when double-clicked it is opened with TextEdit even though BBEdit created it. TextEdit has stolen BBEdit's document.
Again: the key would seem to be the Info.plist key LSIsAppleDefaultForType coupled with an editor role. That creator codes are no longer in use doesn't mean functionality is out the window.
But is there another reason for finally dumping these creator codes from a bygone era? Possibly. Carbon is finally out the door after Apple patiently put up with third party developers dragging their feet for over ten years. Carbon didn't make the transition to 64-bit and that's a Good Thing™. And creator codes are a part of the Carbon that's finally been washed away.
And could there be another reason Neuburg is up in arms? Check the bottom of his article for a possible clue.
Things get really out of hand when Neuburg rounds off by trying to form a posse.
Evidence provided through an anonymous tip suggests that removal of the influence of creator codes in Snow Leopard was deliberately imposed by management on engineering. Since engineering's hands are tied, bug reports to them are likely to be met with the usual 'works as intended' brush-off.
A petition or comments via the public feedback page might be a more effective way to register opposition.
Get someone to go in the trenches for you when you can't bring your software out of the Dark Ages.
Wikipedia: Mac OS
Wikipedia: Mac OS X
Wikipedia: Creator code
Apple: Data Type Registration
Wikipedia: Uniform Type Identifier
TCBD: Type/Creator Database Website
Apple: Introduction to Uniform Type Identifiers
Digg: Snow Leopard Snubs Document Creator Codes
TidBITS: Snow Leopard Snubs Document Creator Codes
Apple Slashdot: Snow Leopard Snubs Document Creator Codes