I wanted to talk about the issues we experienced while running the currently released versions of some of our software products on Mac OS X 10.5. I think this will help people understand a decision we made regarding Mac OS X 10.5, which I'll discuss more about in a future post. This does not cover every problem we saw, just the ones that influenced our decision. This post only discusses the past, even though it may use present tense.

This is a summary of the problems we saw when our current products on Mac OS X 10.5 when no code changes have been made. It's just the currently released product (as of this post) running on Mac OS X 10.5. I'm not going to mention every product, just a few.

All Haxies (Except FontCard 1.5) Running on ICBMs (Both PrefPane and APE Module)

In Mac OS X 10.5, Apple removed the x86 part of an important (and fully supported) library some of our products linked to. In Mac OS X 10.4.x on the ICBMs, this library was fat. On Mac OS X 10.5, it is not. This was never documented and never mentioned that it would not be fat in the future. We used this version of the library as we needed Mac OS X 10.3.x (or as it Mac OS X 10.2.x?) compatibility and the newer version of the library was not made available on those older versions of Mac OS X. We never switched to a newer version as the old version still worked on ICBMs on 10.4.x.

A quick Google search shows we were are not the only ones bit by this undocumented and unexpected change. Back when Mac OS X 10.5 was still being seeded (long before its release), I filed a bug about the missing architecture and was told it was correct. I strongly disagree. This change means none of these products loaded on Mac OS X 10.5 due to dyld rejecting the binary because of linking issues. (Mac OS X does not load binary images if they do not link as of at least Mac OS X 10.3 and later, before the host application would crash).

Note: The only reason FontCard 1.5 doesn't suffer from this problem is because FontCard 1.5 was released shortly before WWDC, and I needed it to load on Mac OS X 10.5 so I could ask some questions about then future directions in the font/text APIs at WWDC. Since FontCard 1.5 required Mac OS X 10.4 or later, I could safely use the new version of the library. I also did it because I wanted to file a bug on the extremely silly and useless dialog System Preferences shows when a preference pane cannot be loaded due to a dyld error, but I needed to make sure the Apple people ignoring the bug didn't think I was filing a duplicate bug on the missing fat library.

Individual Haxies Running on PowerPC (with no changes, in no particular order)

FontCard 1.5

FontCard 1.5 mostly works on Mac OS X 10.5. The only significant issue is the that the Font Panel features that were new to FC 1.5 did not work. Nothing bad happened, the font panel was just not modificated. FontCard's error checking caught the Mac OS X 10.5 changes to the font panel and prevented Bad Things™ from happening. All the font menu stuff continued to work, including support for inactive fonts in third party font sets (which surprised me greatly).

FruitMenu 3.6.4

FruitMenu 3.6.4 mostly works with no serious issues. The only thing that doesn't work is the contextual menu modifications since Apple significantly changed how CMMs are handled on Mac OS X 10.5. I strongly agree with the changes Apple made with regard to CMMs as FruitMenu was often pointed to as a cause of a crash when a buggy CMM was installed. Luckily, the Finder was also blamed for buggy CMMs even if FruitMenu was never installed, so Apple changed the behaviour of CMMs so the Finder would get less blame. Also, loading some CMMs every time on a right click could be a significant performance hit, even if the user never intended to use the CMMs during that click. Surprisingly, click and hold to show the contextual menu in the Finder still works.

Another problem FruitMenu 3.6.4 has on Mac OS X 10.5 is disk operation speed. Mac OS X 10.5 significantly changed disk I/O. It is now low-priority in many cases and doesn't hit the UBC as hard as it used to. I'm not yet sure if either of these changes are good. The end result on FruitMenu is that if you have a large number of items in your Apple menu and you have hot key scanning on, application launches can take significantly longer on Mac OS X 10.5 than they did on Mac OS X 10.4 since the result of the disk operation isn't as aggressively cached as it was before. This becomes an even more significant problem if a Time Machine backup operation is running while you launch an application, as FruitMenu cannot get the results of its disk queries as quickly (Time Machine eats the bandwidth, especially if you use the craptacular and extremely Time Machine unfriendly Mail.app).

Labels X 1.8.2

Let's just say, "Uhm... no...". Labels X works mostly in Cocoa Open/Save dialogs on Mac OS X 10.5, but almost no where else. It does not work in the Finder.

Menu Master 1.4.2

Surprisingly just about every feature in Menu Master 1.4.2 works in Mac OS X 10.5. Even more surprising was that Menu Accelerator works. This is surprising because the menu accelerator feature had to work around a huge number of bugs in Mac OS X 10.4. So either the bugs were not fixed in Mac OS X 10.5 or the Menu Master fallback path (in case the bugs were ever fixed) works. I'm guessing it's a mix of the two.

However, custom hot keys on Menu Extras do not work. This is due to a change in the Cocoa wrapper around menu items (all menus are Carbon menus, even in 64-bit) that Menu Master did not expect. This causes Menu Master to be unable to find menu items in menu extras, thus causing misidentification. This only applies to status items and menu extras (which are subviews of one large Status Item).

There is actually one thing that works better in Mac OS X 10.5 with regard to Menu Master. I had been begging for years for the Menu Manager to support changing the width of menu items while the menu is open. Mac OS X 10.5 brings this feature to the table. This means when a new shortcut is set to a menu item, the system will no longer cut off the text and draw "…" until the menu is reopened. Yes, this is an extremely minor thing, but it's something I've longed for. Yay!

ShapeShifter 2.5

Also, "Uhm... no..." ShapeShifter 2.5 was always designed to not load on Mac OS X 10.5 to prevent any possible compatibility issues. However, this has an amusing result on Mac OS X 10.5. ShapeShifter 2.5 correctly does not do anything on Mac OS X 10.5. However, if you upgrade to Mac OS X 10.5.1 or Mac OS X 10.5.2 after installing a previous version of Mac OS X 10.5, ShapeShifter will warn you about having an out of date guiKit cache. And then it will correctly refuse to load. This is amusing because it's not possible to upgrade your guiKit cache on Mac OS X 10.5, since ShapeShifter won't load.

A second problem is that the ShapeShifter 2.5 Preference Pane crashes a few seconds after load on Mac OS X 10.5.

Silk 2.1.3

Silk 2.1.3 mostly does not work in Mac OS X 10.5, therefore it is an "Uhm... no...". It will work in some places, but won't work in others. It's behaviour in the Finder is very mixed. A few Carbon applications (Finder, iTunes) on 10.5 ask for an undocumented ScriptCode (126, iirc) using GetThemeFont() when opening certain modal dialogs and this makes Silk crash. Luckily, Silk 2.1.3 does not crash at any time before a modal dialog is opened.

WindowShade X 4.1.2

This is also kind of an "Uhm... no...". WindowShade 4.1.2 will not load on Mac OS X 10.5 due to a linker (dyld) error because of a missing symbol.

Xounds 2.4(.1)

Xounds 2.4(.1) (2.4.1 was sent to some users, but never officially released due to what some other users perceived to be a significant bug) is a big freakin' loud, "Uhm... no...". It is the definition of "Uhm... no...". Let's just say that Xounds 2.4(.1) does not like Mac OS X 10.5. In any way, shape, or form. Especially the Xounds daemon. I'm sure you can imagine how bad something can be. Well, Xounds 2.4(.1) on Mac OS X 10.5 was that kind of bad.

Other Non-Haxie stuff

Unsanity Installer 3.6.1

The Unsanity Installer is the application we wrote to install the majority of our stuff that requires an installer. We also allow third-parties to freely use the Unsanity Installer for their own products. It really doesn't have very many features other than what we at Unsanity need it to have. (That is, we do not accept feature requests as it is not meant to be a multi-purpose installer).

Anywho, Mac OS X 10.5 introduces something called "File Quarantine" and "File quarantine" (copied from the Windows XP SP2 feature). This feature shows a dialog whenever you launch a file that was downloaded from the Internets or launch an application that is on a disk image that was downloaded from the Internets. This quarantine attribute is stored in the metadata of the file. When the file is copied, the quarantine metadata gets copied with the file as well.

And thus, we have our problem. The Unsanity Installer explicitly tries to save all metadata on the files it is installing. Sadly, this includes the quarantine metadata. This becomes a super annoying issue for the user as they first see a quarantine dialog when the launch the installer, and then see another quarantine dialog whenever they launch (directly or indirectly) an application that was installed by the installer. Since the Unsanity Updater application was installed by the installer, the user would see a quarantine warning about the Updater when it was launched as part of automatic update checks.

A second problem is the Smart Crash Reports plugin used in the installer suffers from the linker problem mentioned above on Mac OS X 10.5 and will not load (which is a moot point, as SCR 1.2.1 doesn't load on Mac OS X 10.5).

InputManagers:Smart Crash Reports 1.2.1 and Menu Extra Enabler 1.0.3

Smart Crash Reports 1.2.1 was always designed from the get-go to not load on Mac OS X 10.5.

Other than MEE and SCR, we do not produce any InputManagers. None of our other stuff uses the InputManager technology, and thus, are not restricted by the limitations imposed and/or inherent to InputManagers.

That said, Mac OS X 10.5 brings a whole slew of ultimately useless restrictions. Note that not all of the restrictions listed are actually required or true. However, neither MEE nor SCR are installed in a manner that matches the true and required restrictions. This means they will not load in Mac OS X 10.5. They won't even get a chance to decide they don't want to load.

If Menu Extra Enabler 1.0.3 meets all the true restrictions, it will load and will work without any problems. In fact, some third parties are already shipping MEE 1.0.3 with their products and it works just super and jim dandy-like.

Important Note: On Mac OS X 10.5.x, InputManagers must not be installed in the user's home folder (~/Library/InputManagers/) as it will prevent the InputManager from loading even if the InputManager is installed globally in /Library/InputManagers/ and meets all the requirements to load. If you are a developer installing an InputManager, make sure your InputManager is not in the user's home folder on Mac OS X 10.5.x and move it to the trash (FSMoveObjectToTrashSync()) if possible.

Final Thoughts

With all that said, I hope this helps to elaborate a little about the decision we made regarding Mac OS X 10.5 that I will discuss in a future post.

*The above image is courtesy Chilton Webb. Used with his permission. Well, I asked his permission to use the photo for a yet to-be-determined blog post about 2 years ago. He said, "ok", but I do not know if he remembers this permission giving. So, try SuperCard or something.