Schwieb.com

One of the issues I’ve heard customers mention often about Office 2008 is that it doesn’t play well with the Spaces feature that Apple introduced in Mac OS X 10.5. I wrote a long post explaining the issues (almost a year ago! yikes!) and noted that the root of the problem lay in the implementation of Spaces itself in the OS.
I’m very happy to note that with the release of Snow Leopard (aka Mac OS X 10.6) today, Apple has made significant improvements to the Spaces architecture and Office 2008 SP2 now participates quite nicely with the Spaces feature! We worked with a number of people at Apple to identify the set of issues involved and had some interesting back-and-forth discussions on what changes needed to be made where.
So, if you’ve been avoiding using either Office 2008 or Spaces because the two don’t mix well, you can now have the best of both worlds by installing Snow Leopard.

A little over two years ago, I wrote a long post about bugs. In that post, I briefly discussed a number of reasons why not every known bug gets fixed in any particular dot-release of a product. I’m going to go into a bit more detail about one of those reasons today, so allow me to quote myself from that post:

Some bugs are easier to hit, but fixing them may have a high risk of regression and may cause another bug that is even worse. One example might be a performance bug in Excel’s recalc engine. We could fix it and make things faster, but currently the code calculates correctly (albeit slowly) and any fix might totally break all function dependency analysis. It is sad but safer to leave things alone.

Let’s look at performance as an example. Over the ten or so months that Office 2008 has been available, we’ve received a lot of feedback about the suite. One of the most common areas mentioned is performance, such as the amount of time it takes Office apps to boot, the amount of time it takes a chart to draw, or the amount of time it takes Excel to recalculate a worksheet in particular. Each of these three areas are places where we’ve actually put in some significant research and investment in improving Office 2008 performance. Each of the Office 2008 updates (12.0.1, 12.1, 12.1.1, 12.1.2, and 12.1.3) have contained a number of performance improvements, among many other fixes. That said, we’re continuing to make additional improvements. Some of the code changes needed are invasive and we’ve had to evaluate the risk-vs.-reward tradeoffs and make decisions to delay these changes until a more appropriate time.
Let’s look at one of these scenarios. Pretend you are working in Excel and want to create a simple line chart with a large data set that contains as many as 30,000 data points. I’ll presume that you have a pretty good monitor, perhaps running at a resolution of 1600×1200 pixels. Now, your chart probably doesn’t actually fill the entire screen from left-to-right — after all, you need space to show the columns of data that you are working with, right? So let’s further assume that your chart is roughly 1000 pixels wide. That means you are displaying 30,000 data points in 1000 pixels, or about 30 data points per pixel. Even if not all of those data points fall directly on top of each other in the y-axis, the only possible line to draw to connect all 30 of those points in one vertical pixel slice is a single line up and down and up and down again, on top of itself many times. Your chart looks kind of smushed together. Or, let’s pretend for the sake of simplicity that all those 30 data points are approximately the same on the y-axis, and you just get one single pixel, drawn over and over and over again. And, as you may have noticed, the current charting engine that we share with Windows Office is rather sluggish as it faithfully draws that line or pixel over and over and over again.
Now, the fact that 30 data points end up in one pixel slice on the x- axis isn’t the charting engine’s fault, as it didn’t choose the data set or the size of the chart — you did, or you at least accepted the charting defaults. Now, to improve things, you could stretch the chart out to be a full 1600 pixels wide, right? But that doesn’t help much; you’re still at almost 19 data points per pixel. Or, if you had $17,207+tax on hand, you could set up a Mac Pro with four ATI Radeon HD 2600 XT video cards and eight 30″ Apple Cinema Displays (2560 pixels of horizontal space per monitor) for a total horizontal space of 20,480 pixels, which is still not enough space to achieve one data point per pixel! Ok, so perhaps it’s not reasonable to ever expect that such a data set would ever have more than one pixel available for each data point. What would you do? How might you redesign the charting engine to handle this?
One option might be to only plot at most one data point per pixel. But, how do you decide which of the 30 data points is the best one to plot? The first? The middle one? The average value? Do you add math to best-fit the overall line, which adds processing time, which is what you are trying to cut down on? I’ve only mentioned one single possible change, and there are many. The point here isn’t to actually craft a redesign in this blog post (or in the comments either…), but to demonstrate that a redesign can be a complex thing — I’ve posed some design questions and probable decision points already, and I haven’t even considered how the current code is actually designed. (Neither have you, since you don’t have access to it!)
This example is just a very long way of saying that whatever redesign is planned, it has to fit into the current architecture of the code or be willing to accept the risk of changing that architecture and possibly breaking something else. That breakage may in fact be worse than the current bug. If we make a major change to the code, we run the risk of introducing a variety of different possible bugs — incorrect visual representation of the data, or a crash, etc. Testing architecture changes is particularly challenging because it’s impossible to craft a series of tests that exercises every possible type of data that could be charted, and if we miss one edge case we could let a critical bug slip through that is worse than the current problem. We’d rather make the change when we have sufficient testing resources lined up for a longer period of time than we usually have for a dot-release. That way we have all the test coverage needed to validate the change, and is why a bug fix in a feature as important as charting may be delayed.
Bear with me while I shift gears now, and talk about another issue that the MacBU has heard a lot about: Office 2008 and the OS X feature called Spaces. If you read through the links in that previous sentence, a couple of themes pop up:

1. Mac Office 2008 doesn’t work properly with Spaces
2. It happens most often in Word or when the Formatting Palette is open
3. People rarely see the bug in non-Microsoft applications
4. People assume the Mac Office 2008 code base is the cause of the problem

Let me give you some of the background of the Formatting Palette, to help explain why the problem shows up so much more readily in Office 2008 than in Office 2004 or in other applications.
When people talk about the “Formatting Palette” in Office 2008, they usually mean the Toolbox window. The Toolbox is actually two separate windows, bound together by Carbon Window Groups. The first window has the title bar and the row of buttons across the top (the buttons that toggle between the Formatting Palette, the Scrapbook, the Reference Tools, the Object Palette, and whatever else is there that I can’t remember off the top of my head.) That first window is a true floating window created by OS APIs. The second window is everything below that row of buttons, and is the instantiation of one of those toolbox items. These windows are slightly customized, in that we tell the OS to create them with no border or shadow, again through OS APIs. When the Formatting Palette is showing, you’ve actually got the root toolbox window showing first and then the FP window bound tightly to it, on top in the z-order. If you click on the Scrapbook button, the FP window is destroyed and a new window is created to hold the scrapbook, and that new window is bound against the root window. I think that Spaces and Exposé don’t take the window bindings into account (my understanding is that they manipulate windows at the Core Graphics level, which is a lower-level private system interface upon which both Cocoa and Carbon windows sit), and that is why Spaces and Exposé seem to get confused by the root floating window and the upper child window.
The reason MacBU uses this window separation is that most of these child windows are hosted in different modules of code, most of which have their origins in different architectures. The Carbon Window Group APIs allow for very rich and precise control over how windows are presented to the user, and gave us the ability to combine UI from a variety of sources in our codebase with minimal rearchitecting of each of the individual components. The Scrapbook window, for example, is a PowerPlant window because it actually lives deep in the Entourage code (due to the fact that Entourage is currently PowerPlant-based, and that was the easiest way to get access to the Entourage database). PowerPlant is very picky about owning its entire window, which is why we use a separate window here — it misbehaves rather badly if you try to put PowerPlant objects in a sub-frame of a window that is not fully under PowerPlant’s own control. The Formatting Palette is actually a special instantiation of the toolbar code, which has its own assumptions about the sort of window it lives in, and the Compatibilty Report is actually an instantiation of what was originally a modeless dialog.
We have long-term plans to overhaul the entire architecture of the Toolbox and all its clients to use Cocoa, but that didn’t happen in 2008. The Cocoa AppKit window APIs do not yet contain functionality that supports the full richness of window management features that the Carbon APIs do. The Toolbox and its use of Carbon Window Groups were introduced in Office 2004 and predate both Spaces and Exposé. The Office 2004 Toolbox has the same issues with Spaces and Exposé, but you only notice it if you show the Toolbox. In Office 2004, the Formatting Palette was separate from the Toolbox, so the Toolbox was not shown by default. In order to reduce the amount of screen space the Toolbox and Formatting Palette obscured at the same time, we merged the two together early in the 2008 cycle, long before Leopard and Spaces were demoed or available for us to test with in beta.
After we received a beta of Leopard with Spaces, we tested our apps and identified a number of issues that our apps have with the feature. We had an engineer spend several days digging into these issues. He did some serious spelunking into our windowing code and determined that we were not moving the windows incorrectly in our code so we reported them to Apple to investigate. Apple has fixed a number of problems with Spaces in OS X 10.5.3, but some still remain.
So, let’s circle this discussion back to the point I opened with, and the real point of this post: some changes are just too risky for dot-releases, and every company that writes software has to deal with that. Microsoft does and certainly Apple does too. I don’t know the Spaces code — as I don’t work for Apple, I’ve never seen it. Microsoft and Apple work together to troubleshoot customer issues as situations warrant, and as part of that joint effort I’ve spent some time talking to some of the Apple Carbon and Spaces developers over the last few weeks about Spaces. We wanted to see if there’s any sort of change we could make in our code to avoid the issues. If there was anything we could reasonably change in our code at this time I would love to do so. However, changing our windowing system to not use Carbon Window Groups entails a complete rewrite, and is not something we can feasibly do in a bug-fix release. Given the direction Apple is taking with OS X, any significant rewrite of our windowing system should be done in Cocoa, and that is a tremendous task to do in a dot-release. It would almost certainly cause other serious bugs as I alluded to in the charting example above. The Apple developers I’ve spoken with have been unable to come up with any simple code changes to that we could make to work around the issues, and have indicated that our code is generally acting correctly.
For now, you’ll have to wait for Apple to release an update to or new version of OS X where Spaces works with apps that use Carbon Window Groups. Our User Experience team has put up a brief help topic about the issue. We’re keenly aware of our customers’ frustration with Office 2008 and Spaces, and we will continue to work with Apple to help find a solution or workaround. Please continue to share your product experiences with us on Mactopia, or privately with me if you wish. As long-time software developers, it’s frustrating to me and to my peers when we’re unable to fix every problem instantly. Improving your experience with Mac Office on a continuous basis is part of our job. Sometimes we can do it with a quick fix, sometimes not. Your input helps us get it done.
(Edited to clean up the extraneous formatting tags in the last paragraph. Also fixed spelling of Mactopia.)

John Gruber of Daring Fireball linked to a couple of articles today on how to report a bug. First, John linked to this great writeup by Steven Frank, one of the authors of Transmit. He’s got some very good specifics on the sort of content that developers find most useful in a bug report. Second, John linked to a laundry list of ‘Best Practices’ that Apple hosts on their developer site. Much of the specifics related to the format and tools that Apple uses, but the practices themselves line up quite nicely with Steven’s post (and, not terribly coincidentally, with the details that help us in the MacBU.)
Rick Schaut, one of our long-time developers in the MacBU, has a few blog posts about what it’s like tracking down a bug from a developer’s point of view (see Repro, Man and Anatomy of a Software Bug on his blog).
On a related note, I haven’t forgotten about my promise in the comments on my last post about the Office 2008 updaters. We’re still looking at some things internally. I’ve received a number of emails listing details about user setups and what they think the problem is, but when I’ve tried to reproduce the same setup and problems at work, the updaters function just fine. So, I don’t have anything concrete to offer yet. If you are running into updater problems, please consider reinstalling from your original DVD, and keep careful notes about what you do as you run the updaters (see, there was a point to the initial paragraph and title!) so that you can tell me/us as much detail as possible.

The MacBU released a new update to Office 2008 this past Tuesday, to bring the suite to version 12.1.2. There are a number of important fixes in this update, including changes to Word’s boot sequence that can bring a dramatic improvement in boot speed (the exact speed gain will vary a lot depending on a number of factors), major speed improvements in floating point calculations in Excel, and a slew of other items.
Shortly after the update went live, I started seeing recurring reports of people being unable to apply the update. Typically, the updater starts to run, and then mysteriously (from the user’s perspective) says “You cannot install Office 2008 12.1.2 Update on this volume. A version of the software required to install this update was not found on this volume.”, even though the user has Office 2008 installed and has been using it.
We’ve seen these reports regularly, and they almost always happen because of one of four reasons:

1. The user has renamed the Office 2008 folder or some application name inside it
2. The user has deleted some part of the Office 2008 folder they didn’t think they needed
3. The user has run a tool such as Monolingual to remove extra languages from Office
4. The user has run a tool such as Xslimmer or Monolingual to remove extra code architectures from Office

In an ideal world, our installers could handle these cases and complete the install, but installers are complex beasts, and in the interest of reducing complexity, doing any of the above actions is unsupported. Let’s get into each of the issues:
Supporting the renaming of the folder or an app adds complexity because then we have to derive heuristics to guess what bits on your hard drive might be Office. A heuristic is by definition a guess, and for every time we guess right, we might guess wrong. As a very simplistic example, if we have a heuristic that says “look in the /Applications folder for any folder that contains the word Office, and assume that is the Microsoft Office 2008 folder”, then what happens if some other app uses a folder with that name? We’d have to add another rule that says “ok, then look for an app inside that folder named Microsoft Word.app”. That rule can fail too, if users rename the app to be just Word.app. So, we could add another rule, and another, and suddenly the updater complexity just to find Office becomes unmanageable. I don’t think Apple allows their apps to be renamed or moved, either (although I’ve been told by an Apple engineer that they do. I’ll have to check on that.)
Supporting the deletion of parts of Office adds complexity because updates are not necessarily full file or bundle replacements. Some updates are just patches of the executable, or of sub-resources in the app bundle. If you have deleted a particular component that a given update wants to modify, you can end up with only a partial version of that component updated and the rest missing. Office is designed to act together as a suite, and as such, dependencies between the various apps and libraries can change at any time under the hood. If you’ve deleted a library that version 12.1.1 of Word doesn’t need, but version 12.1.2 does, your install of Office would be completely broken if we updated Word after you deleted the now-needed library. So, we err on the side of caution and refuse to update the suite if it has been modified by deleting components.
Supporting the removal of ‘unnecessary’ languages with an app like Monolingual is basically the same scenario as above, although a bit less risky. Interestingly enough, since very few parts of Office actually ship with multiple languages (I think that only MERP, the Help Viewer, and one or two other items have more than one language), removing the ‘extra’ languages only saves you a few KB of disk space, which is pretty small compared to the overall size of Office. Again, however, if you’ve modified Office by removing parts of it, we can’t tell up front whether the bits you currently have on disk will work with the updated bits the updater wants to install, so we err on the side of caution and refuse to update the suite if it has been modified by deleting languages.
Supporting the removal of ‘unnecessary’ architectures with apps like Xslimmer or Monolingual adds complexity because we don’t know exactly what has been done to the software. Did the tool adjust the loader commands in the Mach-O binary? What if we’re patching the binary instead of replacing it? It’s always safer to do nothing to your current install than it is to blindly make changes based on an unknown current state, so we err on the side of caution and refuse to update the suite if it has been modified by deleting architectures.
Some web forums have posted a workaround that involves copying the updater to a write-able location and then modifying one of the scripts inside the installer, so that the installer always blindly goes ahead and applies the update.  That may appear to work, but leaves your Office install in a possibly precarious and probably unsupported state.  [Update: I did a little digging into this script in the updater, and it is checking a number of specific files to make sure they match their expected state.  It is pretty obviously not validating every file in the Office suite (for performance reasons, maybe).  If we’re not validating every file, then it is possible to update some modified file, which undermines my own discussion here.  Hmph.  I’ll have to talk to the folks at work to get the background on this script.  My guess is that we check a representative sample of files to see if they’ve been modified, since the usual suspect processes modify almost every file in the suite.  If one of this set of files has been modified, it’s likely that the rest of the suite has been changed too, and it’s safer to abort the update.  Again, that’s just my guess.]
Now, having said all that, I think the current user experience is not ideal and could be improved. One change might be to tell you that we did in fact find what looked like Office, but that we detected some change that is unsupported (such as language or architecture deletion, etc), but even doing that adds some heuristics, and if we’re looking by name and don’t find the right name, then the current error message is technically correct. So, we’ve got some thinking to do about this.
Hopefully this post explains some of the reasons users are seeing the updater error message. If you are seeing it for reasons I haven’t listed above, please add a comment.

Now that we’ve released Office 2008 SP1, I’ve been able to focus more of my own attention on the next version of Mac Office. We’ve begun the earliest phase of work, internally called ‘EEQ’, which I think stands for “Engineering Excellence and Quality”. The EEQ phase is when we get to tackle important engineering issues that don’t directly lead to a customer scenario, but to help us improve the product at an architectural level. In my case, I’m currently focusing on removing calls to system APIs that Apple has deprecated over the last few years, such as QuickDraw.
During Office 2008, we converted most of our drawing code over to use Core Graphics instead of the historical imaging APIs known as QuickDraw. CG is much richer than QD, has full alpha-channel support and hardware acceleration, and uses floating-point coordinates for full flexibility, so it is to our obvious advantage to use it. Even though we did most of that conversion during 2008, I’m amazed at the amount of QuickDraw cruft I keep finding.
I went through a bunch of our toolbar code today with a peer of mine, and we found dozens of references to GetPort/SetPort, even though the code right next to it was fully CGContext-based. Sigh. Some of them have been trivial to remove, but I’ve also found a lot of mouse-tracking code that uses QuickDraw APIs for comparing points to rectangles. Even the so-called modern OS tracking APIs take CGrafPtrs (I’m looking at you, TrackMouseLocationWithOptions()…) A little more inspection of headers this evening revealed a new replacement API in Leopard called HIViewTrackMouseLocation, but at the moment the Office source code still runs on Tiger, which means I can’t use it easily. Ugh.
Anyway, Apple has deprecated lots of stuff over the lifespan of Mac OS X, and we’ve got a lot of cleanup to do. Reading the Leopard Carbon Release Notes for the HIToolbox gives a sense of the direction to take for the Carbon code that needs to survive. It does feel nice to rip out old crufty code (as my peer said today, “Kill it! Kill it!”) and modernize some of our subsystems. It will feel even better as we transition some of those subsystems to Cocoa. None of this cleanup directly helps our users, but as we modernize our code we make it more maintainable and sustainable for the future, and that gives us a better platform on which to build things that do help you.

Shortly after the MacBU released Office 2008 SP1 yesterday, we started to receive reports that the update caused the Office Setup Assistant to launch every time, instead of their desired Office application. We started looking into it right away, and found that in nearly every case, the problem happens when users are running Office 2008 with an expired product license key.
When Office 2008 was released in January, all of the keys used in our private beta program expired, but it wasn’t until the SP1 update that we added code to enforce the expiration. While we communicated to all of the users in our beta program that their license keys were going to expire when the product became publicly available, one of the beta versions did escape onto the Internet in November and we didn’t know who was using it. During our work yesterday we found that some of our users installed their retail copy of Office 2008 over that beta version and ended up running the final release of Office with the beta key.
Our testing and user assistance team scrambled today and have put a new help topic about the problem up on Mactopia, along with another link to how to remove the old product key information and re-enter your valid key. This is about the fastest we’ve put up new help content — about 26 hours from first report of the problem to active help content!
Also, the English and Japanese versions of the SP1 update are now live in the Microsoft AutoUpdate tool, so rather than finding them on Mactopia for manual download, you can simply go to the Help menu in your favorite Office 2008 app and select “Check for Updates”. The autoupdaters for the European languages should be available soon.
Lastly, we actually put up a very minor revision to the SP1 installer today. The new package has a fix so that the update can actually be deployed via Apple Remote Desktop or via the command-line. If you want to deploy SP1 via ARD and downloaded the update yesterday, please redownload it. If your install is already done and working, there’s no need to redownload and reinstall the update — the fix was in the installer only, not in any of the actual application bits.

It’s finally here! The MacBU has just released Service Pack 1 for Mac Office 2008. You can download the update directly from the Mactopia website (it’s large — about 180 MB), or launch your favorite Office app and select Help/Check for Updates. There are well over 1000 fixes and improvements in this release, including the return of custom error bars and axis tick manipulation in Excel charts. The full release notes are available online as well, so go check them out to see if we fixed your personal pet peeve.
I’m particularly excited to see this update go live, because it’s been the project consuming most of my time for the last several months. Shortly after we shipped released Office 2008 to manufacturing in December 2007, my manager asked me if I’d be willing to act as the development lead for the SP1 project. I agreed, and have spent many hours working on the project since we kicked it off in early January. Since our fine UA department has already written up the list of highlighted changes, I thought I’d spend a little time today describing how we approached SP1 and how we did the work.
First off, while I was the development lead for SP1, I most certainly cannot take any majority of the credit. SP1 was a MacBU-wide effort, with significant contributions from every single developer, tester, program manager, content writer, lab engineer, builder, and all the other disciplines I’m forgetting at the moment. I am incredibly thankful for all the hard work that everyone around me did.
So, why SP1, and why now? Well, it’s no great secret that we released Office 2008 later than our original plans intended. Even after that delay, there was a decent list of issues in the product that were postponed during the original release cycle that we knew we wanted to fix, so we knew that we had to plan for an update sometime in 2008. Mac Office 2004 was first released in May 2004, and its first service pack came out in October 2004, about 5 months later, and that’s pretty much the same schedule we came up with for Office 2008. In addition to fixing the issues we know about internally, we like to have a few months of real user data in hand (crash reports, newsgroup/forum postings, etc) that help us to identify problems that we didn’t know about. I’ve been spending a bunch of time in Ars Technica‘s Macintoshian Achaia forum over the last year or so, and have received a number of good bug reports from particpants there. (In fact, we have a ‘SWAT’ team of folks in the MacBU who participate in a whole variety of forums across the net.)
Anyway, the entire MacBU began development and testing work on 2008 SP1 in January. Initially, teams pretty much just took their list of issues postponed from the regular release and started fixing those bugs. Our test team once again dove into the product and found more issues that needed fixing, and we started to collect MERP logs (Microsoft Error Reporting Program — aka the dialog you see when an Office app crashes) from the wild. Devs took all those bug reports and began working on classifying them by severity and importance, and then started fixing them.
Like any release, however, there needs to be a modicum of control applied to the whole process. If everybody just keeps on checking in fixes, the product can actually end up being less stable than before. The Office codebase is large, and code changes in one part can have unintended consequences somewhere else, so we don’t let code churn run on forever. Many teams at Microsoft (and, I’d imagine, at other large software companies) have instituted ‘triage’ for bugs.
When we triage bugs, it basically means that we take a look at all the aspects of a bug before deciding whether to accept a fix it:

1. How bad is the bug? (Is it a crash? corrupted file? data loss? simple redraw glitch?)
2. How hard is it to encounter the bug? (every time on boot? Only when saving? On Feb 29? Only when dragging a shape across a page boundary when the page is in PubLayoutView and the shape has a semitransparent shadow and the document has never been saved?)
3. Can the user work around the bug? (use the mouse instead of the keyboard?)
4. How complicated is the fix? (simple typo (= instead of ==) or re-architecture of entire function?)
5. Where is the fix? (in the middle of Excel’s recalc engine? Or for populating a single popup menu in one dialog?)
6. How close are we to shipping? (Months, weeks, days?)

All of these factors come into play, and some combination of the magnitude of each of these leads to a decision of whether to fix a bug or not. It can get pretty complicated, and much of it comes down to a gut decision (although we try to collect hard data when we can, like ‘exactly how many MERP reports do we have of this one bug?’) In January, when we were 4+ months away from shipping SP1, pretty much any bug was allowed to be fixed. In April, when we were trying to lock down the code and minimize code churn in order to keep the product stable, we punted a known crashing bug because although the impact of the bug was large, the fix was a little complicated and the testing team didn’t think they could verify that the code change had no unintended side effects with the amount of time left before shipping.
So, what was my role in all this as development lead for SP1? I worked closely with one of our Program Managers and one of our Test Leads as the three-disciplined Sustained Engineering Lead Committee (I have no idea if we had some formal name, so that’s what I will call it here.) Scott, Pat, and I set the product schedule (kickoff, first day of triage, code-complete, zero bugs, release candidate target, etc) and acted as the final arbitrators in daily triage meetings, putting our roughly 33 (ok, now I feel old) combined years of software development experience to use. Mostly that meant that as teams brought their bugs to the triage meetings, we asked them about the above list of questions and tried to get a sense of how each bug fit in importance. We were responsible for using that information to ‘raise the bar’ each day/week — making it harder for bugs to qualify for fixing. That sounds somewhat anti-quality or antithetical to the purpose of a service pack, but actually it is a very important part of ensuring that we ship a high-quality, stable product for our users. It can be very hard to say no to a bug, particularly when people really are passionate about the specific problem or user scenario, but someone has to do it. The three of us all made a final call on each bug, and I think I tended to be the most hard-core about locking things down. Toward the end, a few people jokingly (at least, I hope they were joking) called me “Dr. No.”
As I said at the top, there are over 1000 fixes in SP1, including the re-addition of some features that were glaringly absent when compared to Office 2004. That doesn’t mean Office 2008 is now perfect — I know we haven’t fixed every bug in the product, and some folks are bound to note that we haven’t fixed some of the bugs they are most frustrated by. However, I hope you’ll agree that this update shows that I and the rest of the MacBU are committed to this product and to its future.
Update: I added a new post the other day about some installation problems people have been running into with SP1. If you are having difficulties with SP1 apps, please take a look and see if it helps you.

How does that old Chinese proverb go? “May you live in interesting times!” I have no idea how accurate it is, or whether it is a positive blessing or a curse, but I really do live (and work) in interesting times.
Almost two years ago, back at WWDC in August 2006, the MacBU announced that Office 2008 would not have support for Visual Basic. I blogged about it at the time, and that one post has proven to be my 15 minutes of Internet fame. It continues to be the most popular post on my site — 21 months later, it still accounts for almost half of all the hits I get each week. While most of our customers don’t require the cross-platform scripting enabled by VBA, a section of the Mac community spoke out very vocally against our decision, and I still hear echos of it to this day. At the time, I wrote about the challenges we faced in bringing it forward with the rest of Mac Office 2008 and why we ended up deciding to remove the feature, but while some people understood or at least accepted the details, some in the community did not. I’ve been told that we must have cut VB to intentionally drive users to use virtualization and Windows Office 2007 on Macs, or that we were ordered by upper Microsoft management to slowly kill the Mac, or any one of a zillion other “Microsoft is evil” conspiracy theories. None of these theories are true, but it’s rather hard to prove that, except by deeds.
This isn’t a done deed yet, but I’ve got a new commitment for you. Quoting from a press release that went out from the MacBU at 12:01am PST today:

VBA Returns to Future Versions of Office for Mac
The Mac BU also announced it is bringing VBA-language support back to the next version of Office for Mac. Sharing information with customers as early as possible continues to be a priority for the Mac BU to allow customers to plan for their software needs. Although the Mac BU increased support in Office 2008 with alternate scripting tools such as Automator and AppleScript — and also worked with MacTech Magazine to create a reference guide, available at http://www.mactech.com/vba-transition-guide — the team recognizes that VBA-language support is important to a select group of customers who rely on sharing macros across platforms. The Mac BU is always working to meet customers’ needs and already is hard at work on the next version of Office for Mac.

Yep, you read that right. VB is (well, will be) back, baby! When we came to the realization in 2006 that there was no way for us to keep VB in the product and still ship Office 2008 on any semblance of the schedule we wanted, we announced its removal, but kept looking at how to bring it back into the suite even before we shipped. Many of the technical challenges I wrote about then still remain, but for a while now I and several others have been working with a group of people who know a heck of a lot about the internals of VB, and once we determined that we could achieve the revival VB in the new schedule for the next version of Mac Office, we locked it into place on the feature list.
Personally, I think it’s really cool that we’re announcing this now. For all the wringing-of-hands and gnashing-of-teeth in the Mac community over the lack of VB, Mac Office 2008 has been selling really well (Craig Eisler, our General Manager and all around cool-boss-guy, said “The response has been amazing — since we launched in January, the velocity of sales for Office 2008 is nearly three times what we saw after the launch of Office 2004” in that same press release) which seems to indicate that most of our users don’t find the lack of VB to be a major issue. I think our management is confident enough in our ongoing sales of Office 2008 to tell you about something very significant in the next version, even if that defers some sales to that next version. Based my own experiences talking with people in various Internet forums, I don’t think too much of that will happen, though. And if you were wondering, the delta between Office 2004 and 2008 was longer than we normally expect between versions, so my understanding is that this next version will be available somewhat sooner than 2012 (I can’t give any specifics at this time, however.)
So, if you have a dire need for Visual Basic, you can continue to run Mac Office 2004 (it will even run side-by-side with Office 2008) and we’re publicly committing to VB as good (maybe even better, if things go well) in the next version. My team is responsible for that reintegration, and I’ve been meeting frequently with a number of people as we’ve planned exactly what we’re doing and how we’re bringing VB back. This seems to me to be a strong example for the MacBU naysayers that we’re really listening to what all of our users want, and that we’re most definitely not slow-marching to some bagpiper’s funereal drone!
I’m excited to be able to blog about this now, after almost two years of keeping my lips zipped, and I can’t wait until we reveal everything else about the next version of Mac Office. In the meantime, let me ask you something. What parts of the Visual Basic experience are most important to you? The IDE? Macro UI, such as dialogs? Object model parity between Mac Office and Windows Office? (and if so, which features in the Windows object model do you most want brought to the Mac?) Or something else altogether? I can’t promise to achieve anything in particular, but I’d love to hear how we might be able to improve upon the 2004 VB experience for you.
(Made a few edits this morning, and added a link to the press release.)