(Yes, Betas). While my previous post talked only about the past, this post talks about the present. Some of the previous post is intentionally wildly out of context if you don't read this post. And some of this post may be out of context if you don't first read the previous post.

Standard Goldfish Disclaimer Applies

Remember, these are betas. They have not had the test coverage released software has. But we do have confidence they won't completely make your computer explode. Even so, please open each product's preference pane and make sure automatic updates are checked Daily. Just in case something bad happens, so it'll be no more than a day before you get notified of the update.

These betas also have some significant user interface issues that will be resolved by the time their final release approaches.

With that said, I wanted to talk about the current public betas for Mac OS X 10.5 we are releasing now. But, I'll do it in no specific order.

APE 2.5 (and SDK)

First, let's talk about the situation behind what happened with APE 2.0.1 and Mac OS X 10.5.0 (note that APE 2.0.2 was released on 2006-11-01, a year before Leopard's release, and APE 2.0.3 is the current version). Namely, specifically what caused the issue and what the issue actually was. I am hoping discussing this issue at length will restore any confidence in APE that may have been lost or at least prevent people from pointing to this issue as an argument against APE.

Background

APE is "burdened" by a number of restrictions placed on it. Some are the usual restrictions others are restrictions we've placed on APE from our knowledge and years of experience. Still other restrictions we've placed on APE just because it seems like a good idea to restrict APE to certain boxes beyond empirical evidence (hypothetico-deductive?). For example, "if doing something X is a bad idea, then certainly related action Y is just as bad." We also keep enforcing restrictions that were true on previous versions of Mac OS X, even if those restrictions have long since been lifted by the system itself. We try to respect the legacy. Also, whenever it is decided APE has to call a new API it's never called before, we evaluate who else uses the API on the system (especially if Adobe, Microsoft, and/or Apple applications uses the API) and the chances of a system update changing the previously documented behaviour of said API. We try to choose functions that, if they ever change due to a system update, they will fail in a spectacular and catastrophic manner. So spectacularly catastrophic that Apple cannot release the system update without breaking hoards of Mac OS X's most important applications (this is known as maintaining backwards compatibility).

All of our code contains metric assloads (imperial assloads, too) of error checking and state checking code. If a function returns anything but void, an error check is made (and sometimes even if a function returns void. If something calls into a different API, a state check is made. APE contains about four point three times (if not more) state and error checks than most developers (including developers for embedded devices) would find necessary. With the result of every check being that APE stops doing what it is doing and disables itself if the check is not exactly what we expect it to be or if APE suspects the state of anything has changed. There is absolutely no room for "kind of" in APE.

As an extremely abbreviated example, "this is a green tree". APE would first check to make sure the state is correct. The state being that APE is currently in an environment that can support something that lives, then something that grows (most developers would just assume their application is running above ground on the planet Sol 3, APE makes no such assumptions). APE would then error check to make sure green is a color and that a tree is organic. It would then check the state and make sure the environment has the nutrients to support organic life, then to make sure it supports the combined object "green tree" (that the wavelength of incoming light supports the chloroplasts for a tree and that the wavelength reflected is perceived as green). It would then do a bunch of other error and state checks. Of course, "this" could be a purple tree but APE has never seen a purple tree before. Therefore, APE will disable itself if it sees a purple tree. APE actually does a lot more checks and changes the order of the checks a bit, but this was just an abbreviated example.

That may have been a somewhat tortured example, but it correctly describes the nature and amount of paranoia gone into the state and error checks in APE in a manner that may be understandable to most people. It's also all of I could think of at the time. Sadly, I will continue using this analogy.

The Issue

The higher the level an API is (contrasted with "low-level"), the more leeway Apple has in changing the innards of the API in a system update without breaking documentation. A real-world example of this is the very high-level Cocoa class NSFont. The innards of NSFont on Mac OS X 10.2 and Mac OS X 10.5 have virtually nothing in common. Their implementations might not even share a single line of code, even though all the documented methods for NSFont on Mac OS X 10.2 still work on Mac OS X 10.5.

The problem in Mac OS X 10.5 with APE 2.0.1 is that one of the state checks APE used is rather high-level. In Mac OS X 10.5, Apple made a change so that this particular state check initializes a lot of unrelated subsystems and caches the states of those subsystems. To use the above analogy, it'd be similar to APE querying Mac OS X to determine if the tree was on Sol 3. However, instead of just loading the state of the current planet like Mac OS X 10.4 and earlier did, Mac OS X 10.5 also asks the USGS for the count of the items on the list of named lineae on Europa and then asks the IAU for the list of named minor planets around Ceres.

This became an issue in that the component of APE 2.0.1 that asks for this state check happens to also be a client of one of the unrelated subsystems (configd in this case, used for synchronous notifications of specific state changes). Since configd cannot respond to a query indirectly made to itself at very specific times, this created a race condition that could result in the login process deadlocking. This problem was not caused by a failure or bug in APE's code. (configd accidently and indirectly asked a question of itself and refused to answer until the question was answered by itself.) Due to it being a deadlock, the login process would never continue on Mac OS X 10.5 with APE 2.0.1 installed, no matter how long the user waited. Note: This particular state check is explicitly documented by Apple as being thread-safe, but we do not call it from multiple threads anywho.

I wish to remind everyone at this point that APE 2.0.2 was released on 2006-11-01 and that APE 2.0.3 is the current non-beta version.

This problem should be reproducible in a stand alone application. I've spent a few hours on it here an there, but could never get the threads to align with the moon in just the right way to reproduce the race condition. After a few hours with no results, I stopped trying to reproduce it as I realized I had better things to do than try to make a new project, reproduce the deadlock, and send a bug to Apple. Especially since I knew Apple wouldn't be able to reproduce it due to the nature of race conditions and immediately close the bug as "cannot reproduce".

Sadly, no amount of error checking or state validation on our part could have prevented this issue. It was not a situation we could have tested for as the fact it occurred at all was happenstance.

So you found this problem and fixed it for APE 2.0.2, right?

Yes and no. No and yes. Since the problem only occurred on Mac OS X 10.5 with APE 2.0.1 and not later versions, we looked at what changed in APE 2.0.2 and later that prevented ("fixed") the problem. Turns out that while we were trying to find a workaround to include in APE 2.0.2 for the horrible Rosetta bug, we had realized that if this particular state check (the one in the above section) was ever false, many of the other state checks before it and after it would also be false. Therefore, we could move this state check to a much, much, much earlier place in the code as it was a type of "master control" for other state/error checks. Moving the state check to such a location made the initialization of the completely unrelated subsystems that happens on Mac OS X 10.5 occur at a time at which no race condition could occur.

Furthermore, by the time we moved the state check for APE 2.0.2 (which was around September or early October 2006), the Mac OS X 10.5 seed that developers had was virtually unusable. It would either kernel panic often or couldn't be installed on our development machines due to bugs in the seed. And if we happened to find a machine that it could run on for a while, applications crashed often. And this is all on a completely clean install, with no third-party software installed on it. So we never got chance to find out about this problem before APE 2.0.2 was released. Then again, I'm not sure the problem would have occurred on that seed of Mac OS X even if APE 2.0.1 would have gotten that far. The changes to all the various subsystems in Mac OS X 10.5 between October 2006 and October 2007 (when Mac OS X 10.5 was finally released) were very significant. Some components were completely removed from Mac OS X 10.5 in that time and some brand new components were added.

Basically, we were not aware of the problem when we implemented the workaround. So it was a coincidence that the problem is addressed with APE 2.0.2. It is important to mention this now before I discuss some other things.

Despite the fact that the issue was completely addressed by APE 2.0.2 (released on 2006-11-01), for APE 2.5, we decided to look for an alternative API to get the same state information; one that was not as high-level as the one we used previously (read above for low-level vs high-level discussion). Luckily, such an alternative API exists in Mac OS X 10.4 and Mac OS X 10.5. (You may notice that APE 2.5b1 and all the betas listed in this post now require Mac OS X 10.4 or later). This alternative API fits within all the requirements and restrictions I mentioned APE has above, especially the catastrophic requirement. This new API is also what the higher-level state check we used to use eventually calls to actually get the information we requested. This new API also has a super bonus failure check built directly into it, automatically adding more error and state checking. So it matches our design philosophy quite well. Yay!

Why didn't you test APE 2.0.1 with Mac OS X 10.5 before Leopard was released?

This is a question we've gotten from a few people, but I've never understood why it would be asked since APE 2.0.2 was released on 2006-11-01 and APE 2.0.3 is the current version. Note that the question is phrased here exactly as it was asked by these people. The question was not edited to be more APE friendly.

First, assuming we could have tested it, why would we? APE 2.0.1 was replaced a year before Mac OS X 10.5 was released. If we would have tested it and found a problem, what would our recourse have been? To release an update to APE 2.0.1...? We already did that a year beforehand. All of our haxies have built in software updaters. If the user didn't choose to install any updates that include APE 2.0.2 or later in that year, they wouldn't have installed an update that was released with nothing but a bumped version number (as a form of lip-service). Well, they wouldn't have seen it since our software update has no method of ignoring updates and they would have had to have turned off the updater.

And there are, of course, third party APE Modules and third party utilities that install APE. If these products were updated since APE 2.0.2 was released (since 2006-11-01), they should have made sure their products included the latest version of APE available at the time. Actually most, if not all, of these third party softwares do make sure to include the latest version of APE with their new releases. It's the primary reason why the APE installer is packaged into such an easy to use and easy to distribute file. This single file has all the logic to install, remove, validate, repair, and update APE built right into it. It also allows us to work around bizarre bugs in the system that are necessary to workaround for APE's sake. This is also why we do not permit third parties to modify the single file APE installer itself.

If a third party wishes to make sure they have the latest APE installer in their product, they just install the latest APE SDK. Then they drag and drop the single file installer into their project/installer. The APE SDK also installs the latest version of the non-SDK APE installer to /Library/Frameworks/ApplicationEnhancer.framework/Tools/, so a lot of developers just make copying that file into their installer part of the build process (via Xcode's run script build phase). Doing this means they always make sure they have the latest installer included with their products.

Secondly, even if we wanted to test APE 2.0.1 (as opposed to APE 2.0.3) on Mac OS X 10.5 before it was released to users, we couldn't have. Developers got the ability to download the final build (~6 gigs) of Mac OS X 10.5 at around 3pm on 2007-10-26 and the final developer documentation was not available until around 2007-10-31. Before that, developers weren't allowed to discuss Leopard, even if they had a purchased copy of Mac OS X 10.5 from a store (read that thread, if you have the time or the interest). And the two seeds released to developers before the final (9A559 on 2007-09-21 and 9A527 on 2007-08-24) had a very significant bug that prevented APE (any version) from working. Those versions of Mac OS X 10.5 refused to respect the security restrictions APE was asking for. Because this was a very significant bug, and involved security, we had no reason to believe it wouldn't be fixed in the final Mac OS X 10.5 release. (Yes, it was fixed by the final 9A581 build of Mac OS X).

Due to the nature of this bug, APE versions earlier than the custom build for Mac OS X 10.5 we were using wouldn't have been able to get anywhere. Thus, there was no way to test APE 2.0.1 (or 2.0.2, for that matter) as the bug guaranteed they would not load. If, for some bizarre reason, this bug was not fixed in the final build of Mac OS X 10.5, then at that time we would have figured out a way to work around it and make Mac OS X respect the security restrictions we wanted. We would have done it then, and only then, because when Apple ships a bug in a major version of Mac OS X 10.y.0, it usually stays there until NMOS or NMOS+1 for backwards compatibility reasons. (Also, because it can be hard to convince the manager at Apple in charge of the component with the bug to let an Apple engineer work on fixing the bug and then ship the updated component in a Mac OS X 10.y.x>0 update).

Luckily, because this bug (the one in 9A559 and 9A527, possibly earlier seeds) created an impossible state in Mac OS X (one that violated documentation, common sense, and a few standards), we were able to add even more error checking to APE. As discussed above, we like to add error checking code. There's no reason for us not to test for theoretical cases of failure; you should never test for theoretical success, only success you can verify in practice.

Finally, who's to say we didn't test APE 2.0.1 (as opposed to just APE 2.0.3 or just APE 2.0.3 and APE 2.0.2) on every seed of Mac OS X 10.5.0 that we were capable of testing against? This state check subsystem initialization behaviour may have only been introduced in the later seeds of Mac OS X 10.5.0, preventing any kind of testing by us from finding it. Please do not assume we did not do as much as possible.

I'm sorry if this section sounded overly harsh, but the question is it attempting to answer is a great example of a loaded question. The person asking the question is generally asking it in a rhetorical manner and does often not actually want or care for an answer. Alternatively, they ask it as fully knowing there's no way we can answer it without looking bad or as if we did something wrong, they've already decided what the conclusion is. Thus, it is a loaded question. If the situation was reversed and we asked the questioner a similar question, but one that fits their situation, they would also be at a loss to answer it as we are.

The saddest thing about all of this is that we didn't even know there was an issue until consumers started getting Mac OS X 10.5 in their hands. By that time, it was all over the internets. And there was so much conflicting information that we were unable to understand the situation for a very long time, let alone reproduce it. However, we did update our website to show that APE 2.0.3 did not have the issue as soon as we were told about it (before we could confirm the issue in older versions) and we sent out a notice to everyone subscribed to our mailing list as soon as we could (which was again, before we could reproduce the issue or fully understood it). Due to the huge number of people subscribed to our mailing list, it took two to five days for some people to get the email and by then the story had spread all over the place.

Why do y'all keep repeatedly saying APE 2.0.2 was released on 2006-11-01 (a year before Leopard was released) and that APE 2.0.3 is the current version?

We mostly keep repeatedly saying that APE 2.0.2 was released on 2006-11-01 (a year before Leopard was released) and that APE 2.0.3 is the current version to drive home the fact that APE versions released in the past 16 months do not have this issue. Furthermore, anyone that's updated APE in the past 16 months would not have this issue.

We also really want to convey to people that this issue was addressed long before we knew about it or could know about it (see above and below). A tangential reason for the repetition is that we really want to stress the importance of keeping software up to date. This applies to all software, not only APE. End users can use software tracking sites such as MacUpdate.com or VersionTracker.com. Developers should attempt to add software update checking into their own applications. They can either use a custom rolled solution (such as we do, since our requirements may be "unique") or use an extremely easy to integrate, open source updating framework, such as Sparkle. Yes, our custom updater does need a bit of work and polish, but that work will be done when we have more time to allocate to the task.

I upgraded to APE 2.0.3 and I'm still having this issue || I completely deleted all traces of APE from my computer, yet APE is still causing this issue

No, you aren't still having an issue related to APE 2.0.1. There are a few changes to Mac OS X 10.5 that make it seem like something is failing, a blue screen appears for too long, or that login time is taking excessively long.

I'll list some of the issues that could be confused with this one, but are unrelated to the problem APE 2.0.1 people experienced (note that APE 2.0.2 was released on 2006-11-01, a year before Leopard's release, and APE 2.0.3 is the current version).

Mac OS X 10.5.x no longer shows a progress bar when booting. I think this is the biggest thing people attribute to a problem with APE. When people booted their computer box and it was running Mac OS X 10.4, the user would see a progress bar after the gray screen with the Apple logo. After the progress bar window disappeared, it would show the login window after a very short time of sitting at a blue screen. This progress bar was fake. It had nothing to do with how long Mac OS X 10.4 would actually take to boot. It was simply a program, /usr/libexec/WaitingForLoginWindow, that appeared for the amount of time the previous boot took to complete (this time value was stored in /var/db/loginwindow.boottime). It was absolutely nothing but a placebo there to make the user think progress was occurring.

In Mac OS X 10.5, the boot process has changed a bit. WaitingForLoginWindow and /var/db/loginwindow.boottime are gone. Since launcd on Mac OS X 10.5 no longer supports explicitly listing dependencies and has no StartupItems, there is no reason for the fake progress bar during boot. All launch daemons are launched on demand and in an asynchronous manner. If a launch daemon has an implicit dependency (say it requires a service that another daemon provides) then the launch daemon will block ("pause") until that service is available. As soon as the service is available, the daemon will continue. This allows for multiple daemons to be launched simultaneously and to do as much work as they can before they need another service to be available. All of this leads to a significantly decreased boot time, further obliterating the need for a fake progress bar.

The BootCache. Because loading multiple simultaneous daemons for startup can be slow, Mac OS X has an extensive boot caching mechanism. This caching mechanism is stored in a file, /var/db/BootCache.playlist. This cache significantly decreases the boot time of Mac OS X. This caching mechanism is surprisingly well documented in the BootCache.kext source code. If the BootCache.playlist file is outdated, old, or unavailable, the time a user sees the blue screen on Mac OS X can more than double.

You can actually reproduce this yourself, if you so desire. At least, you can reproduce the longer blue screens display to prove to yourself that it's one reason you may see a longer blue screen irregardless of whether APE is installed. Simply reboot twice and measure the time the blue screen appears for. Then, open the terminal (/Applications/Utilities/Terminal) and run the following command:

sudo rm /var/db/BootCache.playlist

and reboot a final, third time. Time how long the blue screen appears for. It should appear for about 170% to 200% longer than it used to. The /var/db/BootCache.playlist is automatically regenerated on boot. If Mac OS X ever determines the BootCache.playlist is being a lying liar or isn't decreasing the boot time at all, it will ignore it and regenerate a new one. This is also why you see longer blue screens after installing an update to Mac OS X 10.5.x.

If you wanted to reproduce a no progress bar, extremely long blue screen on Mac OS X 10.4, you can open the terminal (/Applications/Utilities/Terminal) and run the following commands (they are on two lines, they are two commands):

sudo rm /var/db/BootCache.playlist
cd /usr/libexec/; sudo mv WaitingForLoginWindow WaitingForLoginWindow.ignore

Then reboot. When you are done playing around and want to restore the original behaviour, type:

cd /usr/libexec/; sudo mv WaitingForLoginWindow.ignore WaitingForLoginWindow

DiskArbitration. As I mentioned above, Mac OS X 10.5 has a lot of implicit service dependencies. Before the loginwindow can appear, and the blue screen can disappear, anything the loginwindow depends on must be up and providing its service.

The loginwindow depends on DiskArbitration (diskarb) to be working before the blue screen will disappear. The problem is, diskarb freezes a lot. Especially if you have external FireWire or USB hard drives connected and their bridge boards are particularly shoddy. Diskarb will completely deadlock the machine until those disks are disconnected from the computer or the disk requests time out (whichever is shorter). This may explain why some people will reboot Mac OS X 10.5 once, see a blue screen forever, reboot, then no longer have a blue screen. Disks usually start responded when they are disconnected or the system has to requery them (which happens on a reboot).

In fact, I have a SATA to USB bridgeboard that thrusts Mac OS X 10.5 into a blue screen 90% of the time, regardless of which computer I test it on. Perhaps I should send this bridgeboard to Apple so they can make diskarb handle this situation better.

Bad Network Devices. One or more of the loginwindow dependencies also query the network to see if it is up. If DHCP is on, it may also query DNS in order to see if your computer has a hostname (to display in the loginwindow, syslogd, in terminal prompts, and some other places. However, the default connection establishment timeout on Mac OS X is somewhere between 10 and 15 minutes. This means that, on shoddy networks, borked routers, or in otherwise weird networking situations, Mac OS X 10.5 may show a blue screen for up to 15 minutes if the network cannot be traversed. After the timeout is hit, an error is returned to the API and the Mac OS X 10.5 booting resumes normally. This would explain some of the reports of Mac OS X 10.5 taking 10 to 15 minutes to boot.

I've personally seen this in a lot of hotels and conferences when the network was down or overwhelmed with requests. This is especially annoying when trying to compile code using xcodebuild as it uses NSHost to try to resolve the current domain name of your computer box even if distcc is disabled (which is considered a bug). It's extremely annoying when you want to compile something but have to wait for the 10-15 minute timeout to expire before anything will start compiling.

Application Enhancer 2.5b1 and APE SDK 2.5b1

As I was trying to explain in my previous post, APE 2.5 will not load any APE module that has not been explicitly marked as compatible with Mac OS X 10.5. See my previous post for reasons on why. We discussed the issue with some other APE Module developers and they agreed that old modules should be disabled. Especially since it's been over 2 and a half years since Mac OS X 10.4 was released and some of these APE Modules haven't been updated since then.

If an APE module cannot be loaded, for whatever reason, the APE Preference Pane will now show the listing why it cannot be loaded. The APE Prefpane now uses the same logic to determine why something won't load as APE itself. Previously, APE itself would have a bunch of undocumented checks and there would be no way for a user to determine why their APE Module wasn't working.

The SDK documentation has also been clarified to mention the APEBundleMessage callback is not called on the main thread. If you need to call functions that are not thread-safe, call them on the main thread using something like MPRemoteCall. Not doing so can lead to unexpected behaviours. It's been an issue in the past, which is why it is now explicitly documented.

Also, the SDK documentation now has a listing of all the Info.plist keys available to APE Module developers as they were never documented before and some are required for an APE Module to be loaded.

• Added compatibility for Mac OS X 10.5.
• APE now requires Mac OS X 10.4 or later and will not install on older versions of Mac OS X.
• Application Enhancer will now refuse to load any APE module that is not marked as compatible with 10.5 on Mac OS X 10.5.
• Addressed some problems with some unpatchables due to the wonkiness of the x86 ABI (Includes APELite).
• The APE prefpane now shows why some APE modules cannot be loaded.
• Removed all references to the Rosetta workaround as Apple fixed that bug in Mac OS X 10.4.9 and the workaround no longer has any beneficial results.
• Worked around a prebinding bug in Mac OS X 10.4.10 and earlier that made APE treat some applications as if they were on the exclude list.

So here are the download URLs for the betas, finally.

Download APE 2.5b1
Download APE SDK 2.5b1

Smart Crash Reports 1.5b2

The biggest change with this SCR 1.5b2 beta is that it now supports SCR entries in the Info.plist of bundles/frameworks (just like applications always could). This was designed specifically for things like Perian, Growl, third party QuickTime plugins, and various SIMBL plugins so they could get crash reports without having to include more code into their products. Such developers should read the Read me in the SCR SDK (installed on the desktop).

I am repeating this as I find it to be very important. 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.

• Updated to support Mac OS X 10.5
• Now supports registering for SCR in Info.plist entries of bundles (Frameworks, QuickTime plugins, Photoshop plugins, Safari plugins, et cetera). Developers no longer need to call UnsanitySCR_RegisterMatchSpecifier() bundles (in most cases).
• SDK: UnsanitySCR_Install now installs Smart Crash Reports with the correct permissions required to work on Mac OS X 10.5.
• SDK: UnsanitySCR_Install now pretends as if SCR is not installed if it is installed inside the user's home folder on Mac OS X 10.5.x as Mac OS X 10.5 will not load SCR from the user's home folder. Behaves as before on Mac OS X 10.4.x.
• SDK: Worked around a problem on Mac OS X that led to repeated calls UnsanitySCR_RegisterMatchSpecifier creating new entries in SCR's preferences when Mac OS X thought that two equal CFTypeRefs were not equal.
• SDK: On Mac OS X 10.5.x, UnsanitySCR_Install no longer allows you to install in a non-global manner due to the new restrictions in Mac OS X 10.5.x. Behaviour on Mac OS X 10.4.x is unchanged.
• Important Note: On Mac OS X 10.5.x, Smart Crash Reports must not be installed in the user's home folder (~/) as it will prevent SCR from loading even if SCR is installed globally. If you are a developer installing SCR, make sure SCR is not in the user's home folder on Mac OS X 10.5.x and move it to the trash (FSMoveObjectToTrashSync()) if possible.

Download Smart Crash Reports 1.5b2

FontCard 1.5.1b1

As I alluded to in my previous post. There wasn't much to do for compatibility with FontCard for 10.5, except the font panel. On Mac OS X 10.5, it's like they gutted the internals of the font panel without increasing (or decreasing) its functionality, which is normally quite a feat.

Please Note: FontCard 1.5.1b1 has not been "certified" for use with Adobe CS3 products (it should work, the worst that will happen is that it won't work). Furthermore, it does not work with Microsoft Office 2008 (the worst that could happen is explosive projectile vomiting). We have not yet acquired these products, therefore we have not tested them with FontCard. FontCard 1.5.x currently has a lot of code for Word v.X and Word 2004 to work around various "quirks" in Microsoft Office. I would not expect FontCard 1.5.1b1 to work with Microsoft Office 2008.

• Added support for Mac OS X 10.5 Leopard v10.5 and later.
• No longer loads Objective-C dynamically.
• Updated to SQLite 3.5.4.
• Now attempts to open third party font sets in read-only mode (possible thanks to SQLite 3.5.0). FontCard never intended to write to third party font sets, only read them.
• Now sorts third party font sets in the font panel (10.5 only).
• FontExplorer stores its database in a different location if your user home folder path does not begin with "/Users/". FontCard now loads FEX sets in these situations.
• Installs a busy handler for FontExplorer sets. This should fix a race condition leading to an error if the FontExplorer application is in the user's login items.

Download FontCard 1.5.1b1

Menu Master 1.4.3b1

Getting Menu Master to work was slightly interesting. Mostly because cocoa's menu manager wrappers now insert a menu item with a NULL title. They then set some attributes on it and finally set the correct title. This was causing Menu Master to misidentify a lot of menus in Mac OS X 10.5. This has been fixed.

Also, Menu Master had to work around a lot of bugs in Mac OS X 10.4 with certain types of windows. Either the bugs were fixed for those certain types, or the bugs remain. Either way, Menu Master still does what is correct for all types of windows.

• Added support for Mac OS X 10.5 Leopard v10.5 and later.
• Dropped support for Mac OS X 10.3 Panther. Menu Master now requires Mac OS X 10.4 Tiger v10.4.11 or later.
• No longer loads Objective-C dynamically.
• Removed calls to many deprecated APIs.
• No longer scans menu items if their titles are NULL or zero length due to an issue cause by the inefficiency of Cocoa menus.
• Potentially addressed an issue with Adobe applications losing custom menu shortcuts when switching documents or not listing all their menu items in the Menu Accelerator window. This required a lot more work than it should have.

Download Menu Master 1.4.3b1

Silk 2.1.4b1

Really nothing special about this Silk other than the pointless new feature to re-enable the Sub-Pixel antialiasing on the translucent menu bar in Mac OS X 10.5 without being required to modify system files.

• Silk now runs on Mac OS X 10.5.
• Dropped Mac OS X 10.3 support. Silk now requires Mac OS X 10.4.11 or later.
• No longer dynamically loads Objective-C.
• Moved a lot of code to the awesomely awesome CoreText APIs (10.5 only).
• Adjusted some code so it can be moved to CoreText in the future.
• Attempted to make Cocoa applications respect the baseline of a font when a custom theme font is used.
• Note: Classic is not supported in Mac OS X 10.5 and the fonts in the Classic fonts folder will not be loaded by Mac OS X. You may have to adjust your Silk settings to address any missing fonts.

Download Silk 2.1.4b1

FruitMenu 3.7b1

• Added support for Mac OS X 10.5 Leopard v10.5 and later.
• Dropped support for Mac OS X 10.3 Panther. FruitMenu now requires Mac OS X 10.4 Tiger v10.4.11 or later.

Download FruitMenu 3.7b1

WindowShade X 4.2b1

• Added support for Mac OS X 10.5 Leopard v10.5 and later.
• Dropped support for Mac OS X 10.3 Panther. Windowshade X now requires Mac OS X 10.4 Tiger v10.4.11 or later.

Download WindowShade X 4.2b1

Final Thoughts

Remember, these are beta. All of these betas include SCR 1.5b2 and APE 2.5b1, so they do not have to be downloaded separately. APE 2.5b1 may also have some fixes for APE not enhancing some applications on Mac OS X 10.4.x in some cases.

Note: We are currently evaluating raising the prices to some of our products. A number of factors contribute to this, including the weakness of the US dollar (I mean, seriously, funny money from Canadia is worth more than the USD). But if this happens, it'll only start to apply when these things go out of beta. The prices for these betas are the same as they have always been. The only change would occur when these things come out of beta and are at a final release. But seriously, Canadian funny money worth more?

Sorry it took so dang long to post these, I've just been various amounts of "not well" for the last few weeks. Sigh, I wish I could ask various doctors on the internets for samples of the sweet blue pill known as Lunesta.

Alternative title to this post was, "Dear APE, I want you inside me. Love, Leopard"