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…

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).

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…