ACP, AWS, CLIX, & Tiger

Keep your hands off the drivers.
 - Ken Thompson

Nothing emanating from Rixstep breaks under OS X 10.4 Tiger. Others apps however do. In general there are two reasons something can break under an upgrade to an operating system.

• The software is interfacing the operating system at a level below 'userland'. Some products have to do this - daemons (device drivers), extensions, et al.

• The software is going where it shouldn't go - and thereby breaking the golden rule.

Apple publish their so-called 'APIs' for a good reason: these constitute the interface software products can use to interact with the operating system. Naturally it is in Apple's interest to keep these APIs constant. If software were to break every time Apple upgraded their OS, havoc would result.

The Apple APIs - the Cocoa AppKit and Foundation - are the result of a lot of serious design thinking and implementation, dating way back to the NeXT years in Redwood City. They're not haphazard and they're extremely well implemented.

And very little of this is going to change. If it's not changed in nearly twenty years, there is little reason for it to change now. It's more than passed the test of time.

Unfortunately, not all software vendors stay on the right side of the fence. Carbon apps are a particular eyesore, using as they do a 'cheat' API that was supposed to be transitional only: Carbon is not a 'true' or 'good' OS interface: it's just a helper for 'legacy' MacOS code and was supposed to be fully abandoned once development teams got up to speed with Cocoa.

Unfortunately, a lot of software vendors are breaking this tacit agreement.

If you invest now in the wrong type of third party software, you will incur difficulties farther down the road; so how do you figure out if your software is true Cocoa or not?

• Is it an '.app'? If your software is not collected in a directory with the extension '.app' it's not going to be true Cocoa. A lot of software can still disguise itself and use this format, but if you don't have this basic structure at all there is little way your software can be using the right interfaces.

• Check inside the package. Cocoa apps will have NIBs; so will Carbon apps; but Cocoa apps will have files called 'objects.nib' - Carbon uses 'objects.xib' (note the one character difference).

• Are there any SCPT files? If so you probably have a 'pseudo-app': an AppleScript monster. AppleScript is a cute way for Cocoa apps to communicate with one another, but running the complete gamut and writing non-trivial software with AppleScript is not going to win any meaningful awards - and it's probably not going to make you happy either.

• What do your toolbars look like? Check the toolbars on your standard Apple apps and the Rixstep ACP apps: these are genuine Cocoa toolbars - Carbon apps can't get this stuff. Carbon apps have dinky little toolbar buttons reminiscent of MacOS. If your software doesn't have 'real' toolbar buttons, it's not going to be 'real' Cocoa.

• Dig inside with 'strings' or Xstrings. Look for references to Carbon libraries and the like. Look basically for the string 'Carbon' - if you find it, your software is using this parallel 'helper' API and not the real 'Cocoa' one.

• Drill down to your executable. Your executable should always be in the Contents/MacOS subdirectory. [If you don't have this structure, see above. Ed.] Once in the right directory, run otool -L on your executable. The output should tell you what libraries your software is hooking up with at runtime. If you find 'Carbon' in there, odds are good you don't have Cocoa software. To know you have software that is at least somewhat Cocoa, you should find references to either the Cocoa, AppKit, or Foundation frameworks.

• Keep drilling down. Some application packages contain further application packages; keep drilling down inside until you've seen everything and apply the above rules to all you find.

• Embedded archives? Some applications obfuscate what they're really doing by shipping code in compressed format; then at runtime they expand these files, run the embedded code, and delete the expansion afterwards so there's no trace of what's been done. At least look for files with the extensions bz2, gz, sit, tar, tgz, and zip; if you find any, expand them and see what's inside - and again apply the above rules to whatever you find.

Even if you don't find anything, you'll have familiarised yourself with basic Cocoa application architecture, something that will be indispensable for you: it's always a good idea to inspect what you got before you take the plunge and run it.