Schwieb.com

So BillG is handing over some more of the reins. Good for him! The B&MGF does some really good work in this world.
There’s been lots of commentary today on what this change means for Bill and for Microsoft. My question for you is what does it mean for the MacBU?
My answer? Probably not much at all. Bill and Steve have both been very aware of our products and plans, and both have been very supportive of our group. I don’t anticipate that changing. As for the effect of the actual shuffling of which top exec does what, in my 10 years at Microsoft I’ve experienced exactly one re-org that had any real effect on my day-to-day work, and that was when the MacBU moved from the Desktop Applications Division to whatever the Home and Entertainment Division was called back in 200x. (And you can see what a large effect it had, given that I can’t even remember the year it occurred.)
The MacBU, like many smaller groups at Microsoft, runs pretty autonomously. That’s one of the things I love about our group — we’re really like a small company, just one that has a lot of support from a much larger organization.
Perhaps that’s a topic to blog on. Another day, however; I need sleep!

The other day, I mentioned my surprise at the lack of commentary on my Cocoa post. I was fully expecting to hear at least one person say that I totally didn’t get it, that Carbon was a dead technology, yadda yadda yadda. Well, one person preferred the analogy that my house was destined to be eaten by termites and thus it was better to rebuild it now than later.
I’m curious to know what the termites are in that analogy.
I saw a very interesting essay on Daring Fireball today. I particularly like this quote from John Gruber:

…in some cases, some people seem unwilling to concede that any criteria other than the ones they themselves deem important actually matter, or even exist.

Now, I’m not pointing any fingers at any specific people. I do believe that the choice to use Cocoa or Carbon is, loosely adapting from John, not a binary choice. It isn’t either-or, and neither option is always better than the other. I firmly believe that there are very valid reasons to use each ‘package’. Saying that ‘your house is going to collapse; you can’t avoid it, so go rebuild it now’ does two things.

1. It denigrates all the work Apple has put into Carbon and continues to put into it.
2. It ignores all the reasons I listed in my post for why we have heretofore continued to use Carbon.

Now, I don’t want to get too dogmatic in defense of Carbon, myself. After all, as I said in my first post and in the preceding paragraph, I believe there are good reasons to choose either platform. That’s why I’m curious to know why some folks are so dead-set on the idea that Cocoa is a magic bullet that can fix anything wrong with an app written in Carbon.
Let me know; we’ll chat about it.

I went back to work for the first time today in over 5 weeks. I updated my G5 and my Intel iMac to the latest Office source code and did a full developer debug build. Well, actually, my iMac did a full build; the G5 was about 60% done when I left. It’s amazing how much faster the iMac is.
Anyway, I was very surprised to see how little commentary my Cocoa post generated. I’ve been playing with some simple stats plugins, and it looks like lots of people have subscribed to my RSS feed (114 feed hits in the last 90 minutes) but I received almost three times as much feedback on my Messenger post. Interesting. (Oh, and jhawk28, I spent lots of time in Middlebury!)
Rick Schaut showed me his entry on bad code today before he posted it. I saw the ambiguity in about 5 seconds, but that’s because it was very carefully contrived. The best part of his particular example is that neither CodeWarrior nor Xcode give any sort of warning that you’ve written Dumb Code. While this example may have been easy to spot, it gets very tricky for devs to hold a mental map of more than a few dozen lines of code in their head. Spotting similar errors when one function is perhaps inlined in a header and another function that interacts with it is at the bottom of a 3000 line source file somewhere else is nigh impossible without actually running the code under the debugger.
Now that I’m back at work, I expect to be blogging less frequently. Please do keep the comments coming; I like to hear from you.

I grew up in a big old farmhouse in the middle of Vermont. You know the kind, with the knotty wide pine flooring that creaks everywhere, huge drafty hallways, shutters that rattle in the wind, old furnace in the basement that sounds like an airplane taking off… My parents bought it in the mid-1970s and promptly had to replace the well that went dry and add insulation to the walls because the winter wind blew straight through it.
The house itself was built in the 1870s and was originally just a summer home, so the kitchen that had been added on in the 1960s was always a little small and never had enough cupboard space for all of my mom’s pots and pans. Last year, my parents announced that they were going to do a massive kitchen remodel and replace the kitchen with a real ‘farmhouse’ kitchen with lots of space for cooking, playing with grandchildren, hanging up wet snow-clothes after sledding, etc. Their plans are pretty impressive — practically doubling the size of the kitchen and adding a mudroom, putting in a fireplace and space for large comfy chairs, a full basement underneath, new fancy refrigerator, and other cool stuff. I just hope it is as warm and friendly a place as the old kitchen where we used to sit around the woodstove with a cup of hot cocoa after an afternoon of sledding down the hill onto the pond across the road.
Ahh, hot cocoa. What, you didn’t guess where I was going with this? Yep, Cocoa. That Cocoa, the one that everybody keeps saying that if only the MacBU would rewrite Office in Cocoa, that it would be magically bugfree, run at warp speed, and somehow still maintain compatibility with legacy fileformats and code ported from Win Office. Well, let’s see, shall we? I’m going to touch that third rail of Mac Development. Let’s see if I live…
If you will pardon me for a little bit, I’m going to draw an analogy to my parent’s house here. I grant you up front that this will not be a perfect analogy, and I fully expect to see comments explaining how badly I miss someone’s point, but you know, no analogy is ever perfect and I’m not a very experienced Cocoa developer (whereas I’ve been writing CarbonLib and InterfaceLib code since 1992).
I see the idea of ditching the Office source code and starting over in Cocoa as similar to the idea of taking an existing house and tearing it down with the intent of rebuilding it precisely as it was before, just with modern tools, components, and technologies. You want to replicate all the character of the house — the creaky boards you love, the rattly shutters, the custom-sized windowpanes, etc. You can do it, but it will cost you a lot of time and money, and you’ll probably exasperate both yourself and your contractor trying to duplicate something that was hand-built long ago.
Or, you can keep your house generally the way it is, and you can take that time and money to add on a neat new addition (perhaps that indoor Olympic swimming pool you always wanted) or rebuild just one part of it in a new style with more capabilities than it had before. You live with the existing creaky floors (you never wanted to change them anyway), maybe you rip out the old furnace and put in a new one with new efficient radiators, but you concentrate your efforts on the new part of the house. You make it extend the old house, yet, because you had a great architect, make it fit in flawlessly so that you don’t feel a sense of shock or dissonance when you walk into that new space.
Moving Office to Cocoa would be kind of like that first scenerio. I’m not saying it can’t be done, or that we’ll never do it; we just haven’t done it yet (as of Office 2004) because the time and effort required are huge, and we can get a lot more out of extending the current source code. If we spent 2+ years rewriting Office in Cocoa, and came out of it with exactly the same feature set as before, how many people would buy it? Be honest now, would you really spend $239 to upgrade Office Standard to a version that was no different than before, from a feature and useability perspective? Oh, you say we could add features at the same time? Yep, we could, but that would take us even longer, and the computer industry moves faster than that!
Rewriting in Cocoa is also no guarantee of achieving bug-free software. There is no such thing. Your contractor will always make a mistake, or your architect will, or the electrician. (When my parents added on a room to the house in 1991, the architect miscalculated the height of the roof by 3 inches, and the builders only figured it out when they went to start putting up the trusses! They had to take the wall frames down and redo them.) Your really smart developer will also always have bugs. We all try really hard to ship clean code, but any system that grows beyond a few thousand lines of code will have flaws. Even Apple has been constantly updating Cocoa in every system release.
Another thing for the MacBU to consider is code compatibility with its own older software and with Win Office. We can’t literally ditch all of our code because we have to be able to read and write legacy files. Moving to Cocoa doesn’t help with that. And, Windows doesn’t have Objective-C, so any code we write in Obj-C cannot be ported to them, and all the code they write in C/C++ is harder to port to us. Plus, our apps still share a lot of common code, so any gratuitous differences in the code make it harder to port features from Win Office to Mac Office (like the new XML file formats.) It’s already hard enough when they write code in C#!
Beyond that, there is always some code you just don’t want to touch (the creaky floorboards and rattly shutters). That might be things like Excel’s recalc engine or Word’s text layout engine. Both are incredibly complex and it is easy to introduce subtle flaws that make the apps almost worthless. Consider the ramifications if Excel miscalculates some spreadsheet for a large Swiss bank. Think they won’t blame Microsoft? Or if Word suddenly doesn’t lay text out the same on OS X 10.5.2 as it does on 10.4.6 because of a change to the Cocoa text engine?
Now, having said all that, don’t get me wrong — Cocoa is a great thing. Our internal infrastructure team has written tons of tools in Cocoa. Just ask David Weiss. Cocoa is really good for setting up a UI and hooking controls and behavior together, and then letting you write the backend. It’s also cool because you can easily subclass all sorts of OS objects and behavior. That’s a pain to do in Carbon where everything is a C interface and you have to write all the glue yourself.
We have lots of plans for Cocoa for upcoming work (no, I won’t tell you when, where, or how — yet) and lots of areas where it makes total sense for us to use Cocoa. In fact, some areas it would be downright stupid of us to do some new features in Carbon. The point of this post is to hopefully help you see why moving to Cocoa is not a slam dunk simple decision. We’re well aware of both the great advantages and great disadvantages of Cocoa and of Carbon, and are making educated engineering decisions on which to use where.

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.