December 2006 – Schwieb.com

A few articles appeared online today, talking about the new Windows Office 2007 file format and converters. They asked a very reasonable question — “Where are the converters for Mac Office?” but wrapped the question in some conjecture and a little bit of hyperbole. Sheridan put up a post over on Mac Mojo to give a little explanation and make a concrete affirmation that the MacBU will release converters for the new formats. So far there have been several dozen comments in reply, many of them expressing some strong emotions ranging from anger and frustration to incredulity and disbelief that we either can, want to, or will actually develop these converters.
Much of the sentiment expressed seems to stem from a number of theories, such as

We have been sitting around doing nothing
We have not talked to the Win Office team
File format converters are trivial

None of these three beliefs are true, however. Let’s look at each one in turn.
1. The MacBU has been doing nothing
The reality is we have been working very hard on underlying technologies we need in order to make these converters. The new file formats are XML-based. On the Windows side, there is a very complete and modern XML parser built into the operating system that the WinOffice team uses. That parser does not exist on the Mac (there are certainly a variety of XML parsers out there, including libxml, but the only one that ships on Mac OS by default is libxml and it doesn’t support everything that the new file formats need.) So, we have spent significant development resources on porting MSXML over to the Mac and testing it to ensure it works. You may recall from earlier posts of mine that porting code from Windows to the Mac is not a trivial task, even when the code doesn’t use any OS-specific APIs. The compilers used by each team are very different, even the behavior of some of the standard runtimes is different, and of course we have to test in great detail any new code and especially any changes we make to it. Beyond that, there are changes that needed to be made to Office 2004 applications to support the upcoming converters, and we’ve been busy doing that. I spent much of the month of October going through Excel 2004’s load and save code path to make it aware of the new converter (I even went so far as to create a fake converter that pretends to handle the conversion commands so that I could actually test Excel 2004’s new behavior as much as possible in advance.)
2. The MacBU never talks to the WinOffice team
Various people in MacBU talk to their counterparts on the WinOffice team pretty frequently. For example, I coordinated the work I did on Excel 2004 with a developer on the WinOffice side who did similar work for WinXL 2003. Our Program Managers have had weekly and monthly meetings with WinOffice folks for the past few years. We’ve known the general plan for the scope of work we’ve needed to do for some time, and have been doing that work. Knowing what to do, however, doesn’t make the work happen instantaneously.
3. File format converters are trivial
Let’s step back and look at the problem again. Office 2007 for Windows and Office 12 for the Mac both need to support the old and the new formats. They need to support the formats natively — it would be pretty silly to invoke an external converter for the new native file format, right? Ergo, the code for the new file format should be written directly into these newest versions of the suites. Ok, so now you’ve got that code in place, and you need to create a converter for the older versions of the suites. What do you do? Should you rewrite or duplicate that file code in the converter project, and risk the converter and the actual product getting out of sync? Or do you take that existing code and repackage it as a converter itself? Well, the WinOffice team decided to do the latter, so their converters for Office 2003 are based off of a significant portion of the Office 2007 code. They shipped their final converter versions after shipping the actual suite that natively implements the formats.
That’s exactly what we’ve chosen to do as well. Rather than duplicating code and having to test each set, we are writing it once and repackaging the appropriate parts as the converters. The problem for us is that we’re following along behind WinOffice in a temporal sense. Because we’re shipping after WinOffice, there is a very real time delta where WinOffice users will be creating files with the new formats and the Mac converters won’t be ready. We’ve been porting the WinOffice code over to MacOffice in stages for many months now, but since they just shipped their final bits in November, we’ve only had those final pieces of source code available for less than a month. We’re porting it over as fast as we can. However, as I mentioned earlier, porting code across is not a trivial task. Our apps have diverged from WinOffice over the last 10 years, so we have to deal with internal implementation conflicts as well as compiler pecularities, OS differences, etc. Some parts even need to be rewritten — anything that deals with graphics on WinOffice probably uses the GDI+ library on Windows, which doesn’t exist on the Mac. So, we need to take time to rewrite it to use CoreGraphics, etc. Those changes need to be tested thoroughly! The converters even need that new graphics code, so that they can convert Office 12-style pictures with all the fancy new effects into some format recognizible by Office 2004.
So, you can see that our Office 2004 converters are very dependent on the progress we make on Office 12 itself. We can’t just drop work on Office 12, as some have suggested, to get the converters ready faster, because the converters use a core subset of the actual Office 12 code. The overall Office 12 project, however, is not yet ready for beta use. The WinOffice file format code changed in some pretty significant ways between their Beta 2 and their final shipping bits, and we had to wait for them to ship so we could get those bits. Our code (not necessarily the file format code, but the whole of Office 12) has some rough edges still; they need to get smoothed out before we can ship.
None of these issues are intractable, insolvable, or something that has surprised us. These issues are just part of the facts of developing and porting code cross-platform (especially code that was not written with cross-platform specifically in mind.) We’re making great progress, and can even see the light at the end of the tunnel (and it’s not a train!) As Sheridan said in a followup comment to her post, back in November we weren’t ready to talk about dates because we didn’t have the latest WinOffice code and couldn’t predict our progress based on missing data. Now that we’ve had the code for a few weeks and have made significant forward progress, I can actually tell you about where we are and when you can expect to see some of the fruits of our labors.
We plan to release a beta of the converters in late March or early April (roughly 3 1/2 months from now), and final versions of them after Office 12 ships. It is imperative that we do proper testing on even the beta converters, because a buggy converter that destroys your files would probably be even worse than not shipping a converter at all. I’m sorry that the wait is so frustrating to you. Many people in the MacBU are working very hard to make the converters available as soon as possible. I’m even helping out by putting on my old Excel developer hat (the one I put on the shelf back in 2001!) and doing some of the Excel port myself. The converters are coming, just not immediately.