And this is far more than just to add a few forms like Apple in iWorks or some Word forms. The trouble whit Word is the formating process. It should be easier as in InDesign but more powerful and precise as in Word.

Rob, we use an internal tool called ‘Source Depot,’ which is a derivative of Perforce. We’ve had between 8 and 15 devs working on the transition at any one time. Office is written primarily in C++ with some legacy C, and is targeted for the most part at the Carbon framework. You can see more on this topic in my older posts.

For those of you seeing so many nefarious plots, I wish you could have been flies on the wall during the myriad meetings we had about VB. This was not in any way an easy or trivial decision. Some of you do raise important points on cross-platform scriptability and I’d love to address them, but I’m unable to comment more on our plans at this time.

There are various points to make in response to that.

1. A subset is compatible, and can be used for a common cross-platform code base if you are sufficiently careful. I’m sure some people are (I am). That will not be possible in the future. That will reduce the willingness of people to provide custom MacOffice solutions.

2. Cross-platform compatibility is not the only consideration. Forward compatibility between versions on the same platform are just as important and possibly even more so. Breaking that means that any company that has made a significant investment in MacOffice VBA code will have to rewrite it all before they can move on to the next version of MacOffice. That may take a while, or might even take forever because they decide that it is easier to stay with the version of Office they have. They might ask themselves why should they pay for the privilege of being forced to rewrite all their VBA code?

Between them, these two issues may significantly hurt MacOffice sales. If they do, Microsoft might decide that the development costs aren’t worth it, and since the new Intel Macs can run Windows anyway, they will just recommend that people run Windows and Office instead. In other words, what we may be seeing is not merely the death of VBA in MacOffice, but the start of the death of the entire MacOffice product line.

I wrote the following article 4 years ago. I think the issues it raises are still current and relevant.

Office and .NET: Better Together?
http://www.ftponline.com/vsm/2002_08/magazine/departments/guestop/

Please do blog further on VBA. I know that there are many people who are confused on why a language designed originally for Intel computers (Windows) can’t be made to work on the Mac. I have a pretty good idea, myself, but I too would like to see it spelled out, as much as you’re able. I can’t understand why the press release did not give any reason whatsoever – it’s no wonder that all the conspiracy theories are coming out once again…

Joshua

(Though I only use Entourage, and that’s actually surprisingly speedy under rosetta.)

Kurt

1. What source control solution do you use?
2. How many developers did you have working on the transition?
3. What is Office written in and what toolkit do you use for the UI? (C++ and Carbon, I presume).

These are just questions that I’ve always wondered about for big apps like Office.

Congratulations on the Xcode switch; I’m dying to see what the next Mac Office looks like, but can you put yourself through talking about the VB decision?

I’m new enough to this that while I’d gathered there were major differences between the Windows and Mac Word VBs, it hasn’t been a problem. So I’d say I was a a minor user but still, a Word macro I created for my own use here on a Mac is now being relied on daily by up to 50 PC users. It’s got to the extent that the name I gave the macro is used here as a verb by people who don’t use Word at all.

And of course I have a slew of my own macros, some mixing in bits of AppleScript, to the extent that this very week I got sick of having all these buttons on my toolbar and I roped them all into a new menu.

I’m so reluctant to throw those away but am I right that I’ll have to if I upgrade or am I just exaggerating the problem?

And I appreciate AppleScript enough now to know that Word is spectacularly scriptable already so I can only be glad that it’ll get even better. Yet can it be a replacement? I have macros that use Word’s great searching features to parse text, can I expect to be able to do that in AppleScript? It feels weird to leave an application to call an AppleScript to delve right back into the app.

I can well imagine what a burden VB was from your point of view, but from mine it’s been a glory and that the fact it can work at all cross platform has been a great bonus. If you hadn’t been moving to Xcode and Universal apps, I’d be asking you to just leave the VB as it was on Office 2004.

Um, any chance I can ask that anyway?

Great blog, by the way; much appreciated,
William