Categories
All MacBU

Spring Cleaning

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.

5 replies on “Spring Cleaning”

Man, it seems like we have to say, “Good grief!” every once in a while, don’t we. Anyway, Schwieb, I haven’t looked at any of the other posts except the one before this to see if there were any comments on my post. I’m just warning you not to try to e-mail me…I have a Managed account on the family i Mac, and it’s running Leopard.

Hmmm…. lots of cruft/crud/crapoola/grunge/rubbish… seems to be one of the defining features of Microsoft code…
And what is this about Office only up to running on Tiger – that software is now well out of date- how about you guys get with the program and catch up with Leopard (you should be just about there when Jobs announces the name for Mac OS 10.7)…
Always a day late and a dollar short…. sigh…..

Boris,
This entire post is focused on “Spring cleaning.” You seem to want to complain about an alcoholic going to Alcoholics Anonymous.
As for the Tiger statement, I believe you mis-inferred Schwieb’s meaning. My understanding of what he’s saying is that Office (as a product) is still backwards-compatible with Tiger. That means that they can’t use Leopard-only calls that wouldn’t exist on a Mac running Tiger, or Office wouldn’t work (since the code libraries from Leopard don’t exist).
Sheesh, Boris, way to think critically. ;P

Michael… I was bored… still… from the comments all this cruft in the code is not exactly an advertisement for good housekeeping on M$FT’s part.
All this extra junk would seem to slow down programme execution and lead to bigger memory footprints – and given that none of the Office programmes is exactly petite when it comes to memory usage then I think it is a fair call…
Take your point about backwards compatibility, but then that didn’t exactly stop M$FT from switching to the new file format. I would take it that it is possible to keep the software Tiger alert (as it were) yet still incorporate the new stuff from Lepoard…
I’m not a programmer at all so I don’t know the ins and outs of all this stuff, but it seems to me that leaving lots of junk lying around is not helping anyone…

Leave a Reply

Your email address will not be published. Required fields are marked *