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.
\nOn 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.
\nHe’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:<\/p>\n
\nHi Erik,
\nI’m calling in a favor. \ud83d\ude42 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.
\nCould 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]?
\nthanks,
\n[Apple Engineer]\n<\/p><\/blockquote>\nI 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:<\/p>\n
\nHi [Apple Engineer],
\nI’m actually OOF on parental leave right now (just happened to be logged in as your email came).
\nIt 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].
\nSo, perhaps [the first API] is returning [XXX] instead of [what you’d expect]?
\n[Here are some other Microsoft devs who] can help you more if you need it while I’m out for the next few weeks.
\nSchwieb\n<\/p><\/blockquote>\nLess than 10 minutes later, I received this reply:<\/p>\n
\n> I’m actually OOF on parental leave right now (just happened
\n> to be logged in as your email came).
\nI just realized you probably were OOF from reading your blog. Thanks for helping out anyways.
\n> So, perhaps [the first API] is returning [XXX] instead of
\n>[what you’d expect]?
\nYes, 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].
\nthanks,
\n[Apple Engineer]\n<\/p><\/blockquote>\nSo, 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.)
\nI 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.
\n(oh and hey, cool, Apple is reading this blog!)<\/p>\n","protected":false},"excerpt":{"rendered":"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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,6],"tags":[],"class_list":["post-53","post","type-post","status-publish","format-standard","hentry","category-all","category-macbu"],"_links":{"self":[{"href":"https:\/\/www.schwieb.com\/blog\/wp-json\/wp\/v2\/posts\/53","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.schwieb.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.schwieb.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.schwieb.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.schwieb.com\/blog\/wp-json\/wp\/v2\/comments?post=53"}],"version-history":[{"count":0,"href":"https:\/\/www.schwieb.com\/blog\/wp-json\/wp\/v2\/posts\/53\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.schwieb.com\/blog\/wp-json\/wp\/v2\/media?parent=53"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.schwieb.com\/blog\/wp-json\/wp\/v2\/categories?post=53"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.schwieb.com\/blog\/wp-json\/wp\/v2\/tags?post=53"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}