If you don't want to read my ranting or the horrible technical inaccuracies someone will accuse me of making, skip to the end of this post to get to the direct download links. Also note that ShapeShifter is not part of this public beta push and will probably be one of the last APEs in a fat binary form due to the extensive image code and other things that have to be rewritten a lot for x86.

Welcome to the first public beta of ICBM-compatible haxies. Slava finally received his ICBM and was able to do some production machine testing. As such, we've decided to release some public betas. In this installment, we have four such betas. Windowshade, FruitMenu, Menu Master, and Silk. If anyone is wondering why I keep calling them ICBMs, it's because it is closest to what Apple calls them. They repeatedly and officially call them "Intel-based Macs". However, that takes too long to type and it has a dash. A nice abbreviation would be IBM. That obviously cannot be used. Especially since IBM makes the PowerPC chips. So the next course is to ask "Intel what?" And answer, "Intel chip". And so we have Intel chip-based Macs, which nicely abbreviates to ICBM. Just 4 short letters. Also, the proper term for "Universal Binaries" would be "Fat binaries". After all, why do you think they call it lipo? What's funny about that man page is that they just did a search and replace for "fat". If you look at the man page dated just five months prior you can see all the mentions of "fat". The other issue with the marketing term "Universal" is that it was previously used to describe application programs that worked in multiple languages. I've also seen a few users think "Universal" is something "magic" (as in something really special) when it's "just" two binaries for two (or more) processor architectures "smashed" into each other to make one larger binary. Granted, fat binaries are an absolutely wonderful thing. They prevent Mac OS X from having 13 different SKUs like what's required for Windows 2003 x86, Windows 2003 "64-bit for 64-bit extended systems" (x64), and Windows 2003 for real 64-bit processors like the Itanium. Fat binaries greatly reduce consumer confusion and are an absolutely great thing to have.

Anywho, I thought I'd write about some of the difficulties we faced when porting stuff over from the PPC side of things to the x86 side of things. Well, I can only really speak for myself and mention the issues Slava's told me about. First, Application Enhancer. That was a doozy. Imagine a small Russian man stabbing an effigy of his mother with a turkey baster while screaming, "Non-trivial! Non-trivial! Non-trivial!". Now imagine his Mother coming in and saying, "Слава, поставь отца на место, пора ужинать." Well, at least that's what I imagine but I'm not all there in the head. APE uses a little more than a bit of ASM. Of course, Mac OS X itself uses ASM all over the place. If you want pure speed and tight control over how your code is run, ASM is the way to go. So porting APE required learning i386 ASM. Not the most difficult thing, especially since Slava was used to 68k ASM from the pre-PowerPC days and I'm told their readability is similar. Learning x86 ASM was just a small bump in the road compared to some other things. Because the x86 instruction set is variable length compared to the PowerPC's fixed length instruction set, some extra work and some design changes on the x86 side of APE were required. By far the biggest thing we had to have was Rosetta support. APE Modules needed to load inside applications running under Rosetta. Otherwise there would be a huge consistency and support issues as running applications under Rosetta is otherwise completely seamless. Explaining to users that they could only run APEs in native processes was completely unacceptable. Adding Rosetta support was akin to adding a large new feature. Debugging APE modules in applications running in Rosetta... Now that's scary.

Application Enhancer was by far the largest and most time consuming part to port over. Especially considering the amount of error checking code we write. The preference panes for the APE Modules were relatively easy. They were mostly just a checkbox away from being loved by an ICBM. But this entirely depends on whether the APE had the pref pane do all the heavy lifting. Some APE modules will make the preference pane "explode" all the data into easy to digest bits since things need to be done as fast as possible on the APE module side of things.

There were a few caveats with porting APE modules. Personally, I found the "change" in objc_msgSend to be my biggest problem APE-side. All normal happy Objective-C calls like [object isEqualTo:object] are transformed into objc_msgSend(object, @selector(isEqualTo:), object...) or some variant of objc_msgSend_*. The [receiver message] type of call is really only accessible to files that are marked as being compiled with the Objective-C "compiler". By default these are .m and .mm files. It's not always possible (or a good idea) to mark files as being Objective-C source code files. For one thing, no APE module can link directly to AppKit (part of Cocoa). It's not that it's not possible but loading AppKit causes an enormous amount of memory to be moved. This can greatly reduce application launch times for non-Cocoa applications. Also, if the host application has an early over-releasing bug (such as PowerMail and Toast did in the way back when that was over 3 years ago) the chances the freed memory being overwritten by another object is exceedingly great, which will result in a crash. Some APE modules address this by creating "sub modules" that only load if the parent is of a particular architecture. However, this can be tedious as it requires an entirely separate code base. Not the most efficient way to do something while weaving in and out of code. Menu Master, it particular, calls objc_msgSend() directly all the time since Cocoa menus are based on Carbon menus. Let's say I want to call a specific method using objc_msgSend but it's Mac OS X 10.4 and later only. I'd need to determine that the object responds to the selector. I'd do this by calling... wait for it... respondsToSelector:. A real-life example is NSMenu's delegate method. If I had an NSMenu object named "lastMenu" I'd test it by running if (objc_msgSend(lastMenu, NSSelectorFromString(CFSTR("respondsToSelector:")), NSSelectorFromString(CFSTR("delegate")))). Now, this would work fine and dandy on the PowerPC. However, respondsToSelector: returns a BOOL type. (Note: BOOL, bool, and Boolean are all different types, do not confuse them.) BOOL is an 8-bit type. objc_msgSend returns a 32-bit type. On the PPC, the upper bits of the 32-bit value would all be zeroed so the conditional check works as expected. However, on the x86 the upper bits are not zeroed. This means it can "randomly" return YES when the answer is an emphatic NO. This can lead to some very ugly crashes. This fix for this is even uglier. It involves typecasting the function pointer itself. So the new check becomes ((signed char(*)(id, SEL, SEL))objc_msgSend)(lastMenu, NSSelectorFromString(CFSTR("respondsToSelector:")), NSSelectorFromString(CFSTR("delegate"))). Fun, huh? When I first ran into this issue in February, I had no idea why I was getting these random crashes. I sent a message out to a mailing list asking for tips. Luckily, someone from Apple responded with a very, very detailed explanation of what was happening and another thing that should be watched. I could not be more appreciative of Greg's response.

Then there's just little convenience things you can do on the PowerPC, like converting a FourCharCode into a C string by using OSType tag='OTTO'; char creatorstr[5]; creatorstr[4]=0; *(OSType*)creatorstr=tag;. Because the x86 is little endian, this will result in some jumbled characters. Luckily for this case, there's a much better alternative in UTCreateStringForOSType(). No ugly pointer math. Ugly pointer math is ugly and makes babies cry.

Yeah, that's just a few of the issues. I had more, but I now realize this thing is getting to be really long.

Onward to the Betas!

After we released Smart Crash Reports and started getting a few crashes in, we were ecstatic. SCR worked and was doing it's job. We immediately fixed the few crashes we saw and released updates. Months passed. We got more reports of the same crashes. At first the thought was maybe the bugs weren't really fixed. We then checked the rest of the crash log. People were still using the really old versions of our software. Sometimes really, really old. With that, we started working on a semi-unified updater. All of these betas include this new updater. By default, it's set to check daily. This can be changed in the respective product's preference pane if you so desire. It's set to check daily because it's beta software. The final release of each piece of software will default to weekly. If you actually desire to change it to something else, please tell us why! If you're behind a proxy, please tell us if manual checking works. It uses the WebKit NSURLDownload class, so hopefully it will work with proxies. That class is just wonderful.

APE 2.0b2

All of these products include Application Enhancer 2.0b2. This beta will expire on May 31st. A design decision was made so only fat APE modules will load on the ICBMs. This is due to the fact a non-fat, PPC only, APE module would only load into applications running under Rosetta and the user would have no way to set the settings of the APE module without launching the System Preferences application in Rosetta. Neither of these are a very good user experience as I mentioned yesterday.

Menu Master 1.3.2b2

Menu Master 1.3.2 includes a brand new feature called "Menu Accelerator". This feature (and it's name) was shamelessly stolen from Gus Mueller with his permission. Of course, his code was not suitable at all (and honestly wasn't even looked at) because it's all Cocoa (see above explanation of APEs linking to Cocoa) so just the idea itself was stolen. Basically, you just press Command Option Control M (4 keys) in an application and a new window with all the menu items appear. You can type into this to narrow the results (see image at right). It is supposed to be completely self-explanitory and intuitive. Sadly most of the beta testers said they wouldn't use it. The only people that did really like it had already been using Gus' implementation before and were glad it finally worked in Carbon applications. I should note that Menu Accelerator uses no patching at all. Carbon Events rule! The DataBrowser does not!

Version 1.3.2 beta 2 (May 16th, 2006-ish)

• Now includes a fat Application Enhancer beta. With tons of fatty goodness and green pea-ness. This beta will expire on May 31st.
• Heavily updated the Menu Accelerator window. It now shows the shortcuts for menu items and shows the parent menu item (if available) of menu items.
• Menu Accelerator now kind of remembers recently searched for strings.
• Added the Unsanity Updater. It's set to check daily by default.
• Some other fixes that I can't remember because I forgot to right them down.
• Sadly dropped Mac OS X 10.2.x support.

Version 1.3.2 beta 1 (March 5th, 2006)

• Fixed a potential infinite recursive loop that would lead to a stack overflow induce crashed if a menu was populated by an event that Menu Master sent, which then caused the event to be sent again as Menu Master rescanned the newly updated menu.
• Addressed a problem that prevented some keyboard shortcuts from being set on menu extras that changed their status based on the modifier keys being held down. This may have a side effect of preventing shortcuts to be set on menu items in menu extras that only appear if a specific modifier key is held down. You can't win them all.
• Worked around a problem that caused a crash in the DVD Player. This was similar to the previous Quicken 2006 problem.
• Changed the way new shortcuts are displayed in the preference pane.
• No longer uses the first parent menu's menu item index when saving menu item paths. This was purely cosmetic and related to the above change.
• Addressed a crash in NoteTaker due to the way NoteTaker's style menu is laid out and handled.

Get it at http://www.unsanity.net/beta/menumaster-132b2.dmg (2.65 megs)

WindowShade X 4.0.3b1 (May 16, 2006, from Slava with Love)

• This update is free for all registered users.
• WindowShade X is now a Universal haxie, working on both PowerPC and Intel based Macs.
• Included the automatic version checker.
• Redesigned the interface of the preference pane.
• Some other pending fixes.
• Includes Application Enhancer 2.0b1.
• Includes Smart Crash Reports 1.1.

Get it at http://www.unsanity.net/beta/windowshade-x-403b1.dmg (3.56megs)

FruitMenu version 3.4.4b1 (May 16, 2006, from Slava with Love)

• FruitMenu is now a Universal haxie, working on both PowerPC and Intel based Macs.
• Included the automatic version checker.
• Redesigned the interface of the preference pane.
• Small fixes.
• Includes Application Enhancer 2.0b1.
• Includes Smart Crash Reports 1.1.

Get it at http://www.unsanity.net/beta/fruitmenu-344b1.dmg (2.70megs)

Silk

Version 2.1.3b4

• Nothing Special here. Updated to APE 2.0b2.
• Removing *some* logging. It still logs a lot for WebKit applications. This is intentional.

Version 2.1.3b3

• Now includes a fat Application Enhancer beta. With tons of fatty goodness and green pea-ness.
• Fixed a crash when opening the about window and then quitting the System Preferences application (reported via Smart Crash Reports).

Version 2.1.3b2

• Added automatic updating functionality with a large hammer.
• Fixes a potential over release of memory if font substitution was enabled but no fonts were set to be substituted.
• No longer have to relaunch System Preferences after entering your registration information in order to see it.
• Greatly reduces the dependence on font families. Silk no longer substitutes fonts based on the stored Font Family ID. This means substitution and changing the theme font should continue to work even if you have duplicate fonts with the same name but different Font Family IDs.
• If the specified theme font is no longer available, Silk no longer replaces the theme font with Geneva (or some other random font).
• Fixed a problem with the new WebKit substitution that would cause WebKit based applications to choose the next font alphabetically on the system if the specified font was not on the system. This bug resulted in some weird effects.

Version 2.1.3b1

• Addresses a display problem with synthetic font styles in a future version of WebKit if font substitution is enabled.
• Fixes the minimum font size settings in applications that use WebKit.
• Addressed a potential problem with the font in the location field in Safari.

Get it at http://www.unsanity.net/beta/silk-213b4.dmg (3.31megs)

Requests for Comments and Other Forms of Love

We'd really like to know what people think about the new APE Preference pane. We tried to clean it up quite a bit and make it easier to use. We'd also like to know what y'alls opinion is of the updating process. That is, what is your feeling on updaters in general? Finally, I'm curious to know which "first tab" preference pane design you like better. The one in FruitMenu and WSX or the one in Menu Master and Silk? Also, if anyone finds any utility in Menu Accelerator. You can answer all these questions and more in the comments here or by emailing us directly. Probably at beta at this company dot com. But only email that if what you need to say can't be said in public on the internets.

Reposting the Links Because it's the Thing to do this Summer (along with seeing Snakes on a Plane!)

WindowShade: Get it at http://www.unsanity.net/beta/windowshade-x-403b1.dmg (3.56megs)
FruitMenu: Get it at http://www.unsanity.net/beta/fruitmenu-344b1.dmg (2.70megs)
Menu Master: Get it at http://www.unsanity.net/beta/menumaster-14b3.dmg (2.65 megs)
Silk: Get it at http://www.unsanity.net/beta/silk-213b4.dmg (3.31megs)

You will see Snakes on a Plane! starring the lovely Samuel L. Jackson.