Author: Erik Schwiebert

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.

Odysseus asked about Pcode in response to my last post, and Rick Schaut answered on his blog. As Rick noted, we compiled C and C++ into Pcode, as opposed to writing in Pcode. You can think of Pcode kind of like assembly language, or better yet, like Java bytecodes. At the time I joined Microsoft, we weren’t using Pcode for any processor-agnostic reasons because, as Rick mentioned, the Windows and Mac OS API sets are so wildly divergent that there’s no point in compiling for a pseudo ‘common’ processor between them.
So, why use it as our assembly base instead of going directly to PPC assembly? Because a major advantage to Pcode is that it is small! Let me get a little geeky for you here (apologies to non-techy readers. If you want me to elaborate on some of the upcoming discussion in a later post, please ask!)
All PowerPC instructions are always four bytes in size, no more and no less. This means that by definition, the average PPC instruction is also exactly four bytes in size. PCode, on the other hand, is specifically designed to make common PCPU (Pseudo-CPU) ‘instructions’ as small as possible, such that the average PCPU instruction is something like 1.2 or 1.3 bytes in length. Now, obviously instructions have to be an integral number of bytes, so this means that many instructions are only 1 or 2 bytes long, and just a few are 3 or more. This means that code compiled into Pcode is on average only about 1/3 as large as PPC-native code (1.3 divided by 4).
Now, since Pcode is obviously not native PPC instructions, you have to have an interpreter to run the code. The Pcode interpreter was hand-coded assembly totaling roughly 10k or so of native code. I don’t recall for sure, but I believe the average Pcode instruction required roughly 20 native instructions to run (standard fetch, decode, execute loop with common instructions optimized to be as close to native as possible.)
So, you have about 1/3 as much code to load, but you are running it on average 20 times slower. Why do this? Where this matters is when your hard disk and memory subsystems are so slow that it is more expensive time-wise to load data off disk than it is to run the interpreter.
Case in point: Mac OS 7.x would load the entire executable code section of your CFM app into memory before executing a single instruction of your application. One particular release (7.5.3?) had a bug where it would actually load the entire data fork into memory, not just the executable part! This meant that the larger your app was, the longer it took to boot. The VM system on Mac OS 7 and 8 was also particularly slow to page data in and out, so if you had minimal RAM and the app was too large, you’d spend inordinate amounts of time waiting for the disk to get your code ready for you. This meant that using Pcode enabled us to fit our code in much fewer pages of RAM and thus avoid the dreaded disk swap.
Some might ask at this point, why not just factor your app into sections, or overlays, and load and unload them dynamically to avoid having so much code in place? That would let you run all your code natively, right? Well, yes, it would, but notice the word “load” in that last sentence? That’s the whole thing we were trying to avoid — the disk! Also, doing dynamic overlays adds significant complexity to your code. (Anybody ever work on 68k Macs with CODE resources? You had to decide what code to put in what resource because the OS couldn’t handle chunks of code larger than 32k! You were forced into dynamic code, and woe be unto those who scattered their code willy-nilly across segments.) Pcode was just simpler and less prone to runtime bugs.
It’s kind of interesting that my very first major task in the MacBU (around March 1997) was turning on Pcode for Excel 98. I was well suited to it, because I was a student consultant for the Introduction to Assembly course in college. When I took it in the spring of 1993, CS314 used Motorola 68k assembly, and then when I helped teach it in 1995 and 1996 we used PPC assembly, so I was Real Good(tm) with PPC assembly and MacsBug. Ahh, MacsBug.
Anyway, we used Pcode for Office 98 and started developing Office 2001 with it too. Mac OS 9 came out little while prior to Mac Office 2001, and both it and the new hardware Apple was shipping were much faster, so the benefits of code compression suddenly became quite a bit smaller relative to the performance hit of the interpreter. However, we were getting too close to shipping and the risk of removing Pcode was to large, so we shipped Office 2001 still using it.
One of the downsides to Pcode from a developer’s point of view is that it is a pain to debug in anything other than a source-level debugger. When you look at Pcode in MacsBug, all you really see is the interpreter instructions; the compiled Pcode is just a bytestream of data fed to the interpreter. This means that trying to track down a gnarly bug in shipping code that has had symbols removed is a real pain. That, combined with the huge improvements in OS X (real VM, anyone?), larger code caches in the new PPC chips, etc, all made the decision to remove Pcode for Office X pretty easy.
More on assembly for Intel and PPC tomorrow (perhaps).

Pip asked about my experiences with Mac Office’s previous compiler transitions. Now that I stop to recall, that is an interesting topic. I joined Microsoft in September 1996, right before Win Office 97 shipped. (I had actually been an intern the summer before, when the product was optimistically called Office 96 internally!) I worked on Win Excel for a few months, and then joined the MacBU when it was formed.
Prior to the formation of the MacBU, the Win Office team really was the entire ‘Office’ team for both Mac and Win products. The debacle known as Mac Word 6 was one of the reasons the MacBU was formed. When we sprung forth, we took a copy of the integrated Win+Mac Office source code with us, and that source became Mac Office 98.
The ‘interesting’ part of that project is that we developed Mac Office 98 using the same tools that the Win Office team used — Microsoft Visual C++ version 4.0. (Remember how I said that we inherited code that was deemed acceptable to a compiler that wasn’t incredibly standards-compliant at the time?) MSVC4 had a PowerPC cross-compiler (it was used for the PowerPC version of Windows NT) that ran on PCs. So, we edited and wrote our code on the PC, compiled it on the PC, and then pushed it over the network to our Macs and debugged it remotely. The process worked reasonably well but could be horrifically slow, especially if you were trying to view a large memory window.
Well, we managed to ship Mac Office 98 and 98-J, and then turned our attention to what eventually became Mac Office 2001. We knew there were some major limitations to our current dev setup:

1. The MSVC compiler had a customized set of Apple OS headers, making it very hard to roll out new headers for new Apple technologies (such as the rapidly evolving QuickTime)
2. Dev productivity was not optimal due to waiting for files to be copied over the network every time
3. Our system required static IPs for our Macs, which ate up corporate network resources unnecessarily
4. Various and sundry other issues
5. We were the MacBU, for Pete’s sake! Why were we working on PCs?

Some MacBU folks began to investigate switching over to CodeWarrior (version Pro 5, or so, i think.) Since I was rather new still, having been at Microsoft for less than two years at that point, I was not involved in the planning or decision-making for that switch. I didn’t actually do much of the conversion work either, being fully involved in making Mac Excel 2001 use Unicode internally. I do recall the conversion taking several months (perhaps 6 all together?) That transition had its own set of headaches, just like our current move to Xcode.
For example, while MSVC only ran on the PC, it could be command-line driven and we had a whole set of scripts, makefiles, custom tools, and other goodies that we used to build Office. All of these had to be redone to work on the Classic Mac OS without a command line. Each custom tool had to be converted from a cmd-line tool to a CodeWarrior plugin. Interestingly enough, we’ve converted now many of them back to cmd-line (Perl and Python where we could; C/C++ still for others) to use with Xcode. Also, CodeWarrior’s parser was picky in different ways from MSVC, so yes, we had scads of errors and warnings to slog through then, too.
Overall, the MSVC -> CodeWarrior transition was shorter and perhaps smoother than our move to Xcode, but Office was a lot smaller then too. We didn’t have Entourage yet, we hadn’t spent 5 more years adding features or migrating more code from Win Office (they hadn’t yet shipped a new version after Office 97 yet), etc. So, it is a little hard to directly compare the transition.
So, all the way back to Pip’s comment: yes, this is at least the 2nd major compiler transition we’ve made. I don’t know what tools were used on versions of Mac Office prior to Office 98 (Rick Schaut would know about Word 5.1 and Word 6). MPW? Maybe, but that would have been a really long time ago!

MacPredict caught my post on our Xcode status, and is asking people to predict when Microsoft will ship a Universal Binary of Mac Office. So far, I see that the ‘consensus’ is January of 2007. Heh.
I’m not going to drop any hints about when we’ll ship, but I do want to point out two things.
1) MacPredict says “it sounds like they haven’t even got it compiling in xCode yet.” That’s not really true. We do have Office building in Xcode; we’re just not 100% done. The vast majority of MacBU devs are using Xcode on a daily basis for the vast majority of their work. We just have a few tricky issues left to work out around a number of core bits of code.
2) The fact that Office builds under Xcode not a very good predictor of when we’ll ship. We’re doing a heck of a lot more in this release than just ‘making it Universal.’ Remember, we were already more than a year into the product development cycle when Steve & Co. announced the Intel switch, with lots of planning done well before Office 2004 shipped.
However, the world just wouldn’t be right without rampant speculation and rumors, so please, go ahead and give it your best guess. Predict away, and we’ll see where we end up.
Full disclosure: I ‘predicted’ June 30, 2006. It’d be nice if we hit this internally… 🙂