Microsoft MacBU developers blogging about the transition to Xcode
Posted by Pierre Igot in: MicrosoftJune 2nd, 2006 • 2:14 pm
Thanks to Betalogue reader Michel for pointing out to me in an e-mail that there are now more MacBU developers at Microsoft blogging about their work, including David Weiss and Erik Schwiebert.
Of particular interest is this recent post by Erik Schwiebert discussing the transition to Apple’s Xcode, which is required in order to develop a “universal” version of Office that will run natively on both PowerPC- and Intel-based Macintosh computers.
Here’s how he describes the process:
Office is so large that the older code hasn’t necessarily been brought up to modern styles/conventions/standards, and we routinely migrate code from Win Office into Mac Office. Win Office uses Visual Studio, which wasn’t always so compliant itself, meaning that we sometimes inherited code that needed some friendly compliance coercion. Our first passes at compilation generated almost a million errors and several million warnings!
it is, of course, something that we all knew already as Mac users, even though we are not developers, because Microsoft products are so visibly non-standards-compliant and so obviously hampered by huge amounts of legacy code.
But it’s good to finally see Microsoft employees openly acknowledging the problem, and virtually giving props to Apple for forcing them to clean up their act:
Apple’s tools, being so nitpicky about code standards, have helped us find and fix bugs in our code and make the next version of Office a better product. At the same time, the sheer amount of code we’ve thrown at Xcode have enabled us to help Apple make Xcode a better IDE, which in turn helps us be more efficient, write more features, and yes, make a better product! Our two companies can and do help each other improve. It’s a great concrete example of how positive our business relationship really is.
Now, whether all this will actually translate into real improvements for the end user in the final product remains to be seen, of course. I am quite sure that, even within the strict framework of standards compliance defined and enforced by Xcode, there are still tons of opportunities to create lousy products with non-intuitive interfaces. And I am somewhat skeptical that, with all this work required “behind the scenes,” there has been/will be much time left for MacBU developers to work on fixing front-end problems.
But at least there is some hope that the next version of Office will feature some substantial improvements made to the existing feature set, rather than just a small pile of new features that no one wants and no one is ever going to use and that will only cause the performance of the product to degrade even more.
I guess time will tell.
June 2nd, 2006 at Jun 02, 06 | 3:53 pm
I love this on David Weiss’ blog:
Ellen Weber asks, “What do you see as the main way to clean up code?”
I’d start with getting rid of all compile errors and warnings.
Assuming 1 minute per error/warning, 1 million of them would require more than 2000 man.days. Not sure we can expect anything anytime soon…
June 2nd, 2006 at Jun 02, 06 | 4:07 pm
I wouldn’t be surprised if Microsoft ended up “ignoring” some of these warnings when the shipping deadline approaches… After all, a warning is just a warning, right?
Seriously, though, my concern is that they might end up “fixing” the errors in ways that significantly affect the performance of the applications. Even with my limited programming experience, I know that there is often more than one way to fix a problem, and that not all fixes are equally efficient and effective.
In other words, the realist in me just doesn’t see Microsoft magically erasing 20 years of patchwork coding in one big software revision cycle. Yes, the next version of Office will run natively on Intel Macs. But I don’t really expect it to be much faster than the current version (which is atrociously slow considering the power of the underlying hardware).
June 8th, 2006 at Jun 08, 06 | 6:18 pm
The process is called “porting” as in “They are the porting the code from Visual Studio to Xcode”. That’s not exactly accurate, as Visual Studio can’t be the previous development environment used on the Mac, but illustrative.
They will have to get rid of all the errors, end-of-story. Compilers emit error messages when they simply cannot find a way to process the source code. Warnings? Some of the warnings will be important, but they may be able to ignore a good number of them, especially if they can say, “Oh, I know what _that_ is being flagged.”
Eliminating errors and warnings isn’t a linear process. Some essentially unique issues will create a gazillion messages; eliminate the cause, and all go away. That assumes that they _can_ eliminate the cause. As we’ve discussed before here, we suspect that Word is currently largely composed of spaghetti code, which we may also have discussed the likelihood of modules of vastly different ages. (Someone mentioned code dating from Word-for-DOS as a possibility.) Compilers, especially advanced ons, can detect poorly-constructed code to some degree, not at a conceptual level, but by finding the kludges necessary to make bad code compile in the first place.
I also suspect that there’s an absolute standing order from the very top “whatever you do, don’t touch the code”. In the process of porting, that would be restated slightly to “Whatever you do, don’t make any changes to the code except the minimum required to get it to buld in the new development environment”. I would guess that much of the work will be done by people who don’t understand Word at all. I suppose there may be some cases that someone of broader skills will be called in to sort out what’s actually going on — if they have anyone with that capability.
In sum, porting a well-constructed code base from one environment to another could be fairly easy to do. Porting poor code could be a nightmare.
What boggles my mind is that there apparently are two code bases, one for Mac and one for PC. The core of Word –the bulk of the code– should be identical for both, especially after all these years. It’s long since been routine among vendors to maintain multiple-platform applications this way. Yes, of course, the UI and the system interface code will vary, but there are quite standard ways of dealing with this variation.
We’ve previously discussed some of the potential problems of legacy code. Who knows, the “sort-of multitasking” built into the idle loop in Word for DOS or Word for Early Windows may still be present in the current code base — we’ve seen some evidence that may indicate that. Such measures were justifiable kludges in their time, but are long since completely archaic and increasingly difficult.
If Xcode is a good compiler, it will produce efficient code — if the underlying design is, in fact, efficient. If it is not…