OSNews

Yeah, whoever edited that site needs to take another look. And since when is Microsoft limiting testing unusual? lol

Edited 2007-12-11 23:22

Too bad VBA/macro support was dropped from Office:Mac 2008. I think a lot of people (myself included) will pass on the upgrade just because of that.

Does Microsoft think the Mac is becoming a business environment threat to the Windows juggernaut? Maybe I'm missing something, but what other logic could be behind that decision? Just ran out of time, maybe? Oh well, so much for cross-platform compatibility.

Actually the issue was the MacBU developers were not up to the challenge of converting the ancient vba code in Office for the Mac over to Xcode, or in their own words it would have taken an estimated 2 years to get the job done.

Reading about it I got the feeling that they barely touched the vba codebase on PPC and likely hoped it would 'just keep working' with each office release.

The switch to Intel by Apple made these guys throw in the towel on vba support on the Mac.

You can read about it here and yes it sucks, but after reading this I can't say they made a bad decision.
http://www.schwieb.com/blog/2006/08/08/saying-goodbye-to-visual-bas...

Edited 2007-12-12 07:40

There are no doubt people in the MacBU who could implement it, but doing so compatibly would be quite difficult. And they don't have a huge staff.

That was clearly a case where the code was excessively-optimized. It probably had to be done at the time, but it came back to bite the MacBU now.

Thanks for the link. That's the kind of explanation that I was looking for. Still, it's dated from August 2006, almost 18 months ago. If they only had been given the resources, they could almost be done with a VBA re-write for Intel (given the requisite two years development estimate that you mentioned).

It sounds like those in the MacBU genuinely regret not being able to include VBA support, it's just disappointing that upper management decided not to give them the resources to do so. Sure would be great to see it included in a future version, though.

I meant that if management had created a team entirely dedicated to re-writing VBA for OS X on Intel, it wouldn't have taken time away from the normal Office for Mac team.

I understand that the investment may not have been justified, even with Microsoft's cash reserves; but it's disappointing nonetheless.

It'll be interesting to see what happens with AppleScript, but it seems like a bit of a pipe dream to expect things to work well with the VBA scripting used in Office for Windows.

OOXML supports the embedding of arbitrary application-speific or document-specific custom data into the document container. So yes, VBA macros can be used with OOXML by just embedding a macro file in the Zip container. This isn't specific to VBA, though. Heck, you could probably embed a theora file into a Word 2007 document if you had a OLE object the supports theora. Or if you're using something like OOo to produce your OOXML files, it could potentially put its own script format into the container. My main point is that the VBA data is an application-specific extension to the OOXML document. For the usual interoperability case of exchanging documents between organizations, VBA shouldn't matter (you really should be careful when using macros written by people you don't trust).

I don't know what's going on exactly with VBA. It looks like there are more and more .NET tools for office coming online. What I'd personally like to be able to do is to use IronPython to write Office macros, since that is my current preferred scripting language.

There was a blog link in an earlier comment... the reason is pretty prosaic: the VBA runtime did a binary translation of the precompiled VBA bytecode to PowerPC. Rewriting this JIT compiler, which was apparently not portably-designed, simply did not fit on the Mac Office team's schedule.