Now that we’ve released Office 2008 SP1, I’ve been able to focus more of my own attention on the next version of Mac Office. We’ve begun the earliest phase of work, internally called ‘EEQ’, which I think stands for “Engineering Excellence and Quality”. The EEQ phase is when we get to tackle important engineering issues that don’t directly lead to a customer scenario, but to help us improve the product at an architectural level. In my case, I’m currently focusing on removing calls to system APIs that Apple has deprecated over the last few years, such as QuickDraw.
During Office 2008, we converted most of our drawing code over to use Core Graphics instead of the historical imaging APIs known as QuickDraw. CG is much richer than QD, has full alpha-channel support and hardware acceleration, and uses floating-point coordinates for full flexibility, so it is to our obvious advantage to use it. Even though we did most of that conversion during 2008, I’m amazed at the amount of QuickDraw cruft I keep finding.
I went through a bunch of our toolbar code today with a peer of mine, and we found dozens of references to GetPort/SetPort, even though the code right next to it was fully CGContext-based. Sigh. Some of them have been trivial to remove, but I’ve also found a lot of mouse-tracking code that uses QuickDraw APIs for comparing points to rectangles. Even the so-called modern OS tracking APIs take CGrafPtrs (I’m looking at you, TrackMouseLocationWithOptions()…) A little more inspection of headers this evening revealed a new replacement API in Leopard called HIViewTrackMouseLocation, but at the moment the Office source code still runs on Tiger, which means I can’t use it easily. Ugh.
Anyway, Apple has deprecated lots of stuff over the lifespan of Mac OS X, and we’ve got a lot of cleanup to do. Reading the Leopard Carbon Release Notes for the HIToolbox gives a sense of the direction to take for the Carbon code that needs to survive. It does feel nice to rip out old crufty code (as my peer said today, “Kill it! Kill it!”) and modernize some of our subsystems. It will feel even better as we transition some of those subsystems to Cocoa. None of this cleanup directly helps our users, but as we modernize our code we make it more maintainable and sustainable for the future, and that gives us a better platform on which to build things that do help you.