Month: June 2006

Pip asks about why Cornell has switched CS314 from 68k to PPC to MIPS assembly. Since I graduated 10 years ago, I don’t know why they’ve made the switch to MIPS. My guess is that it is mostly up to the professor du jour. My advisor is the one who switched to PPC after teaching it in 68k, and I think it was because he was very gung-ho about RISC. At one time I knew some 68k, PPC, x86, and SPARC assembly because I took classes that used all of them. SPARC was weird — it has this concept of sliding register windows, so that data you put in one set of registers as output parameters to a function you call can be ‘slid’ to be called ‘input’ to the called function. I think we used that for my compilers class. Nowadays, I know PPC inside and out, but barely recall 68k. I had totally forgotten x86 assembly and am relearning it on a daily basis now… 🙂
sneumann and Nik want to know about Cocoa. Well, I can’t comment on specific directions the MacBU may be going with future products, but I think I can safely say that we are always looking to use the technologies that make sense (to us, at least.) We’ve already shipped small bits of Office 2004 using Cocoa, and we’ll be using it where it has the best bang for the buck as we go forward. Did you know that MERP, the dialog that comes up when an Office app crashes, is done in Cocoa? If you haven’t already seen it, you should read Rick Schaut’s (slightly) dated post on Carbon vs Cocoa.
Jack asks about rumor sites — do we read them, and do we officially learn things from Apple before everybody else, or do we have to follow the rumors ourselves? Yes, some of us read them. We actually have a team of people for whom part of their job is to spend some time reading the various forums on some of the sites and respond to posts asking about Office. They also take bug reports from those forums and enter them into our database. And sometimes we just bust a gut laughing at some of the rumors about Mac Office. As for learning things from Apple ahead of time, the answer is “It depends.” Since we have Non-Disclosure Agreements with Apple, we see some things early that they want to show us, like Software Updates, or Xcode, etc. The really big things, we learn about the same way everybody else does. For example, I personally learned about the Intel switch by following the keynote just like everybody else.
And yes, i did get some more sleep the next night… ZZZZZzzzzzzzz!

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!)

‘gmprice’ commented on my ‘Brief History’ page about a sordid tale of setjmp. Heh. Yeah, I remember that too, but it is pretty technical and I realized I don’t know what sort of background or interest in nitty gritty technical tales of compiler dependencies you folks might have.
So, heck, let me ask you what sort of posts you’d like to see… Go ahead, comment away, tell me what you are interested in about the MacBU. I make no promise to post on all requested topics, and in fact probably won’t get to them all anyway. I’m sure some of your requests will be for things I just cannot blog about (current or future products, Microsoft proprietary information or policies, etc) but within reason, I’ll do what I can.
I myself am curious to know what you are curious about.

The way I wrote it at the end of my post on Mac Messenger may have sounded like I was kidding, but in all seriousness, the MacBU is indeed hiring. We’ve got several jobs open for developers, testers, and program managers. Some of the positions are based at the Microsoft main campus in Redmond, WA and some are based at the Silicon Valley campus in Mountain View, CA.
Follow this link to see all currently open positions at Microsoft that refer to ‘Macintosh’ somewhere in their description. If the Product field says “MAC Office” then the job is for the MacBU. (And yes, I know, I hate the all-caps MAC too. We didn’t do it!)
At least for developers, Mac experience is not necessarily a prerequisite, although it certainly helps. We’re just looking for smart, motivated people who love to write code and are happy to do it on a Mac. Submit your resume using the links on the page and it will get to us. Please do not submit it here on my blog, as it doesn’t get into our system from my personal web site!

I saw this link in a post on Scoble’s blog today, and it made me think of all the work the MacBU does for its international software releases. Shall I tell you about it? (Too bad if you said “No!”)
In an earlier post, I told you how a large part of my day-to-day job over the past year has been driving our transition to Xcode. That’s not all I do, however. I’ve been very privileged to have been the US-based point-of-contact in MacBU engineering for our localization work ever since we started work on Office X. I work to coordinate the efforts of our localization teams in Dublin, Ireland and Chofu, Japan.
Internally, ‘localization’ refers to the whole process by which we take a piece of English software and create the Japanese or whatever version. This includes everything from the actual translation of the text elements to tweaking the layout of dialog box controls to renaming certain files on the disk images to actually assembling the disk images for the new languages. Additionally, localization involves ensuring that we don’t use any politically or socially incorrect terminology in any of the product languages, including English. We currently localize Office into Japanese, French, German, Spanish, Swedish, Italian, and Dutch.
My role is basically to provide developer expertise in this area to the teams in Ireland and Japan, as well as to assist our Redmond and Silicon Valley-based developers in making their feature designs localizable. Features are localizable when they don’t hardcode strings into the source (use resources instead like .strings files), don’t hardcode string substitutions (since the order of subjects, objects, and verbs changes from language to language), allows for dialog and control layouts to shift (German text tends to be up to 1/3 longer than English, so dialogs have to be able to reflow to a larger size), etc.
I don’t do any of the actual translations, however. I speak enough Japanese to wander around Tokyo and look for Studio Ghibli goods (I found a cel from the opening credits of Tonari no Totoro for my son’s room the last time I went to Tokyo), but not to do any official business work. I’ve forgotten almost all of my high-school French, and while my last name is German, I can’t even count to 10 in that language…
Anyway, back to localization. ‘Loc’ is a very important thing to get right. Look at this laundry list from Nicole Simon’s post that I linked to above:

There are not many tablet users in Germany, but many may be interested in using one. I could be a blogging about how happy the tablet makes me, but I have to admit, I cannot. Because it does not let me do the stuff I want to do – and therefor I do not expose my peers to it.
I will not blog much about Flickr, because it uses English and all the help and exposure I could give would be irrelevant because I would need to do translation as well.
I will not blog much about Google Spreadsheet, because the first thing people will notice is that you cannot even start to use it for German calculation.
I will not blog much about Office 2007, because it is unusable for me and I also assume that I will not be able to even install it without bigger problems on my machine.
If you look at my examples they may sound non relevant, but they are little step stones toward a bigger picture: We do get used to ignoring you over here because you don’t care about us. And while we are busy conducting our lives, you bring one firework after another – just on the other side of the earth ball.

Politics aside, we can’t afford (literally) to mess up the localized versions. We’ve got to get all these little things right — and I don’t think her list is so little. Consider Excel. We’ve got scads of code to do things like Japanese Imperial date formats, commas instead of periods for European decimals, translated function names for cell formulas, etc. And, all that data that gets saved into the file has to look right when opened in, say, English Excel. So we have to be able to map from SUM to SUMME and back for German Excel, for example.
The really tricky part of localization is that much of the work has to happen after we’ve locked down the visual aspect of the current release. It is expensive to keep translating and retranslating text of a feature that is in flux. Yet, over the last 10 years we’ve gone from a 6-month delay between English and localized releases to somewhere on the order of 2 weeks delay. This means that we’ve compressed the same amount of work into less time, so that the international Mac community gets their hands on the next version of Mac Office at almost the same time as English speakers do. That compression means that we don’t have much time to fix bugs in the main codebase that are only revealed by the localization process!
One of the ways we deal with that is a process called ‘pseudo-localization.” This has nothing to do with ‘pseudo-code’; instead, it is a way of forcing text into some translation automatically, yet still have that text be mostly readable. It works by taking the normal Roman alphabet and changing each of the characters into some similar character, perhaps one with an accent, or a copyright symbol instead of a C. We also pad each string with extra text to make it wider to check for dialog mis-layout and string insertions.
So “pseudo-localization” might become “[=== pséü?øløçålîzå†îøñ ===]” — still mostly humanly-readable, wider to force dialog layout, and bracketed so we can tell if a dev hardcoded string insertions. We can do this in an entirely automated fashion, and this technique lets us test perhaps 50% of Office as if it were localized, so that we can catch obvious dev mistakes right away. We thus reduce the risk of finding a bad localization bug so late in the release process that we can’t fix it safely. Pseudo-loc does sometimes generate bogus bugs (for example, if it auto-translates something into a value the code never expects, like “10” into “[=== 10 ===]” and we are only expecting a series of digits) so we can’t use it for everything.
It takes a lot of work, and I’m very proud to be a small part of our international efforts. I know we don’t get it all right, but we try our darndest to make our software relevant, useful, and usable by the international community.

Several people have now asked about Mac Messenger. More specifically, they’ve given a list of feature requests with A/V at the top. So, why don’t we have it? When will we get it?
Mac Messenger is a product in active development (yes, really!) so I can’t answer either of those two questions directly. I’ve been able to share a lot of MacBU’s back story because that’s all about work done in the past, not about work currently being done or future work in planning. However, for the same reasons that I don’t share feature lists for the next version of Mac Office, I won’t do it for Mac Messenger either.
That said, I can give you all a little bit of insight. Here’s what I’d like you to know: The MacBU is a medium-sized group at Microsoft (at least from my perspective) but compared to either the Win Office team or the various incarnations of the Messenger app on the Windows platform, we’re actually pretty small. The MacBU has a grand total of 52 developers (including leads and managers). A quick query across Win Office shows roughly 550 developers, meaning they are over 10x larger than we are. Yet they own only Office; we own and produce Office, Messenger, RDC and Virtual PC. Because these products are mostly in active development simultaneously, we spread our 50+ developers across these products and thus have relatively small teams. To make our numbers feel even smaller, we’re often doing maintainence work (or even feature work!) on older releases of our software. Did you notice that we have released two service packs for Office 2004, and that both of them had some very large features in them?
So, to the case in point: Messenger. Our Messenger team currently has a total of three developers working on it, plus one open headcount. The average size of the team has remained pretty constant at 4 or 5 developers for the past several years. With such a small team, we have to make tough decisions for each release as to which major features to include, and which ones to cut. For the latest major release (v5) the major feature add was Corporate communications, to tie into the LCS architecture.
Separately, the MacBU has to consider cross-platform compatibility. Just as one of the main selling points for Mac Office is the degree to which it is compatible with Win Office, Mac Messenger must remain compatible with Win Messenger. This means we have to use the same codec as they do, speak the same chat protocol, etc. Perhaps we could add some easy QuickTime video codec and hook up with iChat’s protocol, but that doesn’t help us talk A/V to all the Win Messenger users out there. Porting the Win Messenger codecs and protocols is probably a lot of work (I don’t know how much, or how many people it might take, or how long) but I’m willing to bet it would be a significant investment and large proportion of the available dev time for our small team.
Of course, we could pull other devs off of their other projects and put them onto Messenger, but that has its own problems. The MacBU’s income that it contributes to Microsoft as a whole comes largely from its two main products, Mac Office and Virtual PC. Messenger is given out freely, and any return on that investment comes primarily from the value add it brings to the Office suite and for its compatibility with Win Messenger. We have to seriously weigh the ramifications of the loss of our primary revenue stream. Ok, so that sounds like I’m a corporate shill, but it’s the financial truth of any business, no matter how large or small. If I run a little espresso stand, I’ve got to keep making coffee drinks, no matter how cool it might be to add something like a free valet parking service, right?
My impression (and I may very well be wrong) is that the comments I’ve received about Messenger have been from people wanting to use it for personal use, as opposed to inside a corporate network. As such, I guess that the corporate chat feature is largely useless to you. Since I don’t work on Messenger, I don’t know all the details of why that particular feature won out and others didn’t, but I’m sure the team (devs plus program managers and testers) all had to make some very hard choices. Our choices obviously did not satisfy Matt, priit, or Nik. How does that quote go? “You can please some people some of the time, but you can’t please everybody all of the time,” or something like that.
As for audio and video, believe me, we know how much you want it. We hear about it all the time and we’ve certainly heard the howls of anger coming from the various public forums on places like Ars Technica and MacNN each time we’ve released a version without A/V. Perhaps we’ll get a version with it someday. Perhaps even soon. For now, you’ll just have to wait and see if we surprise you.
I know that’s not the answer you were looking for, but that is the honest truth.
Hey, if you want to help us make a version with A/V and you’ve got the right L33t Mac Skillz, you could always apply for a job in the MacBU.
/me ducks and hides…

The comments made against my last post on trusting MacBU mostly relate to the oddly named product ‘Windows Media Player for Mac’. Several people ask why its quality is so poor, and why the MacBU hasn’t done anything to fix it.
Well, I can’t really answer the first question, but the answer to the second question is easy: WMP-Mac is not and never was a product owned or produced by the MacBU. WMP-Mac was actually ported to the Mac by a small group of folks either in or closely linked to the main WMP-Win team (which, depending on your perspective, may be the answer to the first question.)
I got to thinking about this today as I wandered around the house with my daughter. No team at Microsoft really spends any effort telling customers what products it owns or doesn’t own. For the most part, that’s because it is relatively obvious — the Xbox team owns, umm, the Xbox, right? Yet the MacBU is in a little bit of a different spot. Because Microsoft as a whole makes very few Mac products, the average consumer might reasonably expect that the ‘Macintosh’ Business Unit at Microsoft would make all Mac products at Microsoft. Except that isn’t true…
The MacBU makes Mac Office, Mac Messenger, the Mac version of Remote Desktop Connection, and Virtual PC for Mac. We do not make and never have made WMP-Mac, any Mac hardware or drivers, the Windows SFM client, or Mac Outlook 2001. Yet we’ve shipped WMP-Mac on our Office CDs and in the past we’ve publicly referred people to Mac Outlook 2001 as an Exchange solution, so that confuses the issue.
One way this confusion over product ownership really adversely affected our trustablility was over a couple of press releases. Look at these:

• Microsoft Commits to New Versions of Office for Mac
• Windows Media Components for QuickTime, by Flip4Mac

Look closely. See the dates? Both PRs were released on January 10! My understanding, which may be wrong, is that neither the WMP-Mac team and Telestream nor the MacBU knew about the other pending press release and agreement. Thus, on January 10, it looked like Microsoft-the-uber-company was simultaneously saying “Hey, look, more Mac software” on one side, and “Hey, look, less Mac software” on the other. That’s essentially what this article claimed.
There was so much wrong with that article it was almost comical. Yet, from a trustworthy perspective it really burned us. What really got me was that the author was in such a rush to post “OMG Microsoft is abandoning the Mac” that they didn’t wait to actually talk to anyone at MacBU! Sure, there’s a tag at the bottom saying “Microsoft didn’t comment,” but hey, we were all busy at MacWorld explaning just what our new 5-year commitment meant. Better yet was the unnamed “sources” saying that “key developers in the MacBU” had been assigned elsewhere. Folks, that doesn’t happen here. Employees have open careers at Microsoft; its up to the employee to decide if there’s a job somewhere else at Microsoft to which they’d like to switch. As a matter of fact, we’ve had several devs from other non-Mac groups move into the MacBU!
Anyway, where I was going with all this is that as unnecessary as it may seem to us internally, maybe it would make some sense for us to more visibly call out MacBU products as ‘Made by MacBU”… I dunno — I’m most definately not in marketing or public relations and I’m not any sort of upper-level manager, so I don’t have the experience to make any such recomendation.
In any case, now you know what products the MacBU is responsible for. Feel free to praise or criticise those as you wish, but please don’t hold us accountable for that other product over there. 🙂

Scoble posted yesterday on trusting your friendly neighborhood blogger. He talks about communicating without solely thinking of ‘business’. I like that. I think part of why I’m posting so much about work and the things I’ve been involved in with the MacBU over the years is that I’d like to see people trust us a little more.
Ok, now that you’re done laughing and have wiped the milk and cereal off your monitor…
No, seriously. While it was before my time, Mac Word 6 really struck a blow to Microsoft’s credibility on the Mac, and the MacBU has had a long row to hoe to get any of it back. I’d like to think that we’ve done so with everything we’ve produced over the 10 years that I’ve been here. John Welch commented(warning: he’s a bit opinionated!) on the MacBU’s recent work in light of the new 5-year agreement that we signed with Apple in February, and I think that while he’s a little rough on Tom Yager, John does call to light everything we’ve done.
Every day I see so many rants and conspiracy theories and panic attacks and oh, just silly comments made by people. Ever read the commentary on Remote Desktop Connection? The vast majority of the feedback is really positive, and then there’s this one. Sins of the father, I guess?
That’s why I’m here; to give people a chance to see more of MacBU. We’re Mac folks, we’re human, and hopefully you can see us as that, and not simply as a preconceived notion of the Evil Empire. I guess what I’m saying is if people trust me, maybe they’ll start to trust the MacBU a little more.
I’m not asking people to trust us in the hopes of making more sales, or because I’ve got some marketing message to push; I’m asking because I’m a developer who likes what I do and who likes the people I work with, and I’m proud to have contributed to our products over the last 10 years.