There are two significant aspects to Microsoft's recent announcement regarding Office:Mac (see MacWorld coverage).
First, the good news: Office Mac is going Universal, so MacIntel users will have a native build for their new MacBooks and Mac Pros. Good news, which should be reassuring for the long-term viability of the product.
But almost as an aside, the announcement mentions that MS will be dropping VisualBasic support from Office:Mac, making it not quite as Universal. Now, I'm not exactly the biggest VB fan in the world, as anyone can attest. But I do know that an awful lot of businesses rely (for better or worse) on large, complex macros and VB scripts to stitch together their business processes with Office documents. This undermines the ability for a Mac user to fully and equally participate in an Office environment that relies on such VB macros, thus relegating Office:Mac users to second-class citizens.
For example, a friend of mine works in an organisation that uses macro-laden spreadsheets to implement their timesheet and billing system. Until now, an Office:Mac user enjoyed complete compatibility with their Windows peers, and one could freely use a Mac if they so preferred, and still participate in the Office document economy. No longer... will they be forced to switch to a PC now, just to fill out a form? Or maybe switch to OpenOffice.org?
Update 14-Aug: A very insightful and honest post from one of the lead developers on the Office:Mac sheds light on the matter and the reasoning behind the decision, including lots of technical detail. Apparently the developers faced some very tough decisions on how to support VB going forward into Universal support. They are painfully aware of the impact of the decision on users, but are limited by time and resources.
It turns out that the VisualBasic front-end parser builds a series of opcodes from the macros. These opcodes are then processed by the engine backend that generates assembly code on the fly, doing all sorts of complex register allocation, variable mapping and so on. All this is obviously highly architecture-specific, thus making portability a nightmare.
Also, the Forms module (the GUI component of VBA) does all sorts of funky tricks, like swapping vtable pointers of C++ objects and features lots of custom assembly code.
Apparently the Office:Mac codebase has sufficiently diverged from the original Windows codebase that porting the newer implementation would be just as problematic, as even the object model is different, and the features between the Mac and Windows versions are not in sync.
To make matters even worse, this part of the codebase was written before most of the current developers joined the project, so there's hardly anyone left who actually fully understands how this code is designed and how it actually works. They have been trying to hire more developers for some time, without much success.
As a developer (who puts a huge amount of effort into writing portable code), one inevitably ends up questioning many of the design decisions that led to this path, as it seems standard practice for Microsoft to bake in features that are inherently non-portable (and potentially just difficult to maintain). But it's easier with 20-20 hindsight, and the MacBU at Microsoft are obviously doing the best they can under the circumstances. So if you're a Mac developer in the northwest, why not check out positions at Microsoft? Millions of Mac users would be grateful...
Leave a comment