Playing nicely together

A week or so ago, I noted how beneficial our move to Xcode was for both Apple and the MacBU. As part of our close relationship with Apple, we’ve been able to test pre-release seeds of Xcode and of the various OS versions. One OS we haven’t seen yet it Leopard. (Perhaps after WWDC this summer?) However, we also have developed lines of communication with individual Apple engineers over the years. We’ve been able to direct questions about OS behavior right to the folks who can see the code, and get definitive answers as well as suggested implementations if we run into OS bugs. The neat thing is that it works the other way, too.

On Wednesday I received an email from a particular Apple engineer with whom I’ve had lots of contact over the years. He had encountered an issue running Word 2004 on Apple’s internal Leopard builds and was looking for some information from us to track down the bug.

He’s given me permission to share our ‘conversation’ with you. I’ve sanitized the emails (my edits are in [square brackets]), but it generally looked like this:

Hi Erik,

I’m calling in a favor. :) I’m trying to track down a bug that occurs on the next version of Mac OS X (Leopard) that causes Word to [do something that makes no sense]. Specifically, [Word calls an API with two parameters that don't match properly]. The call to [the API] is coming from Word itself. I’m trying to track down where Word gets the [data] that it passes to this API. I’m assuming it’s coming from the OS somewhere, and something has changed in Leopard that is causing Word to [use mismatched data], but I don’t know what’s changed.

Could you pass this email onto whoever owns the [feature] in Word, and ask for some info about how Word gets the [data it then passes to the OS]?

thanks,
[Apple Engineer]

I launched Apple Remote Desktop and connected to my Mac at work. I knew the directory that contained the code in question, but not which file or function, so I started grepping for the API he mentioned. I found that pretty quickly and started searching for callers of the code in question. After a few minutes of tracing call chains and a few variable names in a particular structure, I found what I thought was the likely source of the data. I replied:

Hi [Apple Engineer],

I’m actually OOF on parental leave right now (just happened to be logged in as your email came).

It looks like we [call one API to get the data from the OS, and if the returned value is XXX then we call this other API and use the value from that call instead. The value from that call looks like it would be the bad data you are seeing].

So, perhaps [the first API] is returning [XXX] instead of [what you'd expect]?

[Here are some other Microsoft devs who] can help you more if you need it while I’m out for the next few weeks.

Schwieb

Less than 10 minutes later, I received this reply:

> I’m actually OOF on parental leave right now (just happened
> to be logged in as your email came).

I just realized you probably were OOF from reading your blog. Thanks for helping out anyways.

> So, perhaps [the first API] is returning [XXX] instead of
>[what you'd expect]?

Yes, it looks like it. I had changed the [OS] code to set the [data] using a [different data type], and removed the [code that handled the value Word was using]. The bug is fixed if I restore the code that [handles that value].

thanks,
[Apple Engineer]

So, within the space of an hour or so, we managed to fix a Leopard bug that was exposed just by launching Word and looking at one UI element. (As it turns out, the code in Office that was relevent was written against OS X 10.1. We can probably make a code change that would be more correct on newer OS versions, and would avoid the internal OS dependency. Office is currently relying on some well-documented but slightly deprecated Carbon behavior.)

I bet the above email thread doesn't sounds like much since I edited out all the specifics, but my point is more general -- that Apple and Microsoft can and do help each other out in simple ways that foster a very positive dynamic relationship between us.

(oh and hey, cool, Apple is reading this blog!)

3 thoughts on “Playing nicely together”

  1. Dear [Apple Engineer]

    It looks like there is very annoying bug in the print API used by MS Word. This bugs happens when customer print a document with section break that were inserted to allow them to change page orientation within the same document.

    As you know, this force Word to print separate document, and creates to our customer many problems from:
    - not being able to use 2 side printing properly, nor staples from their printers
    - not being able to create PDF

    This you are working on fixing some stuff for leaopard, could you take a look at this!

    Thanks

    Oh, and BTW, could you ask Steve to just buy out Thrusby and bundle dave and AdmitMac within the OS. This will so much simplify the life of our commun corporate customer pledge with SMB problems/limits of the standard MacOS functions

    ;)

  2. Is there people at MacBU that spend their time rewriting old code into “more correct” code? Or did you do that only when old code makes Office crash?

  3. Define “more correct”.

    Most software programming take the form of “if it’s fixed, we’re not going to break it”. Any time you change code, you run the risk of introducing a new bug. That’s why towards the end of software projects, bugs that are found will NOT get fixed if the user impact is trivial (“User must stand on head and type under a full moon while chanting verses from the Necronomicon to get this display issue in this dialog to show, it doesn’t crash or cause data destruction, and we’d need to do three week’s worth of retesting if we make any changes. We’re not fixing this 3 days before we release. We can get this on the next release.”).

    Do teams do stuff like refactoring or other Good Things? Sometimes, if they have the time and there’s good reasons to do it. But again…every time you touch working code, you run a risk of breaking it. So anyone who does commercial software development on a large project doesn’t just do this for fun, or for some desire for arbitrary code purity.

Comments are closed.