Saying goodbye to Visual Basic

Wow, I always had a feeling VBA was somehow sickening, but this definitely proves it. Kind of cool that it works at all, though. Is Win Office 2003/2007’s VBA any “better”?
Perhaps there’s room for a VBA to AppleScript converter (either by Microsoft or a 3rd party), to at least decrease the pain a little less for those who rely on it.

Already talked to two of my enterprise customers have already said they will not upgrade and will now look at just moving those users to the PC as Excel with out VBA is useless to them. Guess MS got what they wanted.
-d

You described what you regard as the two driving requirements behind MacOffice
1. it must be as Mac-like as possible, use Mac features, and take advantage of the Mac operating system, and
2. it must be as compatible with Win Office as possible, and share as many features and commonalities as it can.
But what this misses is a much more basic requriement for a new version of *any* program
– It must provide sufficient new features to justify the overall cost to the customer of the upgrade
The “overall cost of upgrade” is not just the price label on the box. It is the whole cost of testing that the new version doesn’t mess things up, the cost of training if necessary, the increased support costs of confused users phoning the help line, and most importantly in this case, rewriting any add-ins or other custom code that stops working.
I’ve heard it suggested that fewer than 10% of users make any use of macros. Maybe so, but I would guess that nearly 100% or corporate customers have some significant use of macros *somewhere* in the organisation – even if only for a very small proportion of their users, and that these macros in many cases have grown, perhaps quite unintenionally, into mission-critical apps. Their importance may not even be recognised until they stop working. Such a thing is sufficient to abort a rollout across an entire company even for those users in the company who make no use at all of macros.
It is a fact of life that people value the features they have and use now much more highly than the features they might obtain through purchase of the next version. They *know* the value of the features they have now – they are speculating on the value of features they haven’t tried yet.
I accept your description of the technical difficulties. I accept that most Mac applications don’t have or use VBA. But 100% of Mac Office installations *do* have it, and you will build a huge roadblock to corporate acceptance once the meaning of this starts to sink in. It is not just Windows cross-platform compatibility that needs to be considered, it is forward compatibility between successive versions of Office on a single platform. This decision breaks that in a way sufficiently fundamental to call into question the willinglness of any large organisation to upgrade. Why should they pay you for the privilege of being forced to rewrite all their custom code?
What is more, you will be appear to be reneging on public commitments on the subject. Steven Sinofsky (at the time the Group VP in charge of Office) has made several public statements that VBA would remain in for “at least the next two full product cycles” of Office. The first of those is Office 2007, and (to answer Chris’s question) VBA is there, and Microsoft demonstrators at technical conferences have been falling over themselves to say that VBA can still do everything it could do on the old version and can access new features such as the Ribbon.
Does that promise not apply to Mac Office, or has the promise lapsed altogether now that the person who made it has been moved over to be in charge of Vista?

Personally, I could care less about VBA since in all my years of using Office, I have never used scripting in my applications. If I really want something scripted, Ill do it in Java, Ruby, etc. I’m glad to hear that MS is making some hard decisions and pulling stuff out of their software that is just dead weight. I think we will see a better, cleaner product in the end. Since OpenOffice keeps being brought up, I think that it is an ok product. Its ok if you don’t might an ugly interface… Its ok if you don’t mind waiting 30 seconds for it to load… Its ok if you don’t mind some of your documents looking funky… The real competition is coming from Pages and Keynote as they are pretty nice apps.
Joshua

I think the fundamental lesson learned by MacBU from the Word 6 fiasco was that “the app must be Mac-like at the expense of cross platform compatibility.” The lesson that should have been learned was “don’t force Windows interfaces on crappy code that makes the Mac slow.” In other words, don’t make crappy apps for the Mac.
At this point, it would seem to me that the best thing to do is the bring the Windows Office code and use that as the base and make the interface Mac-like. It’s not that we don’t want the functionality, we certainly want the features. We just don’t want the Windows UI forced down our throats. If that means that the next version after 2007 doesn’t run on PPC, that’s just fine with me. Work together with the WinOffice team to create cross-platform applications… forcing more code onto crufty code circa 1995 is certainly not working for you.
Finally, a blog doesn’t change impressions: Actions do. I once told Kevin Browne that instead of getting on stage and saying that you’re committed, show us real committment. In the past few years, you have abandoned IE, Windows Media, VBA, and VPC. Actions speak infinitely louder than words.

Thank you for posting this.
Have you considered interpreting the VBA opcodes instead of compiling it to PPC?

Chris – it sounds like MacBU does little more than maintain and port code so that they can maximize profits with minimal maintenance and new development costs. It’s really that simple. If you want to do something, you find a way to do it. Basically, they looked only at fixing the old code and not a new solution that would address current and future needs.

I’ve always tried to avoid being the angry Mac zealot who needlessly bashes MS, but I can’t support a company unwilling to fully support my platform of choice.
I think you guys are missing the point WRT Open Office. Users aren’t threatening to move to Open Office because they think they’ll find VBA support there — they’re threatening to move to Open Office because VBA support is the only thing that ties them to MS Office. If VBA support disappears, MS Office loses its value, so why not use a free tool instead.
Looks like I won’t be opening up my wallet for Office 12.
As a curiosity, was the idea of dropping PPC support ever floated? If this is such a massive undertaking, I think Intel-only support would be perfectly reasonable…

One problem with converting their VB code from this assembly compiler to C++ is that VB is a pretty hard language to parse. Typically if you were to do this you’d do it in YACC. In fact I’m surprised that even back in the 90’s they didn’t have some YACC and C code to do all this – the fact they wrote effectively a compiler is actually impressive in a way, but also probably the reason for some of the existing incompatibilities between VB on Windows and Mac version of Office.
I suspect it still could be done, but if they are having trouble finding qualified people it’s understandable. If they had the budget though finding a YACC wizard and assigning him the task might be interesting. Once you have the language working right I suspect a lot of the C code for doing the actual functions could be salvaged. (Yeah, easy to say from outside – especially when I don’t know how modular their code is)

Anonymous-san: They couldn’t possibly drop PPC support for the next version of Office, when half the Macs will still be PPC; and I don’t think there’s any way that a VBA component could exist only in Intel mode inside a Universal Binary app. But I imagine that whatever eventually surfaces as a cross-platform program language in some future version down the road (Office 13 or later) could then be Intel only, coded fresh.
Erik, thanks a lot for the detailed explanation.

Thank you for devoting so much time to clarifying this issue for us all. I feel better knowing how serious the issues are, and how heavy the decision was. However, a few questions still remain, and it would go a long way towards softening the (huge) blow if you could answer them as best as you’re able and allowed by your employer.
1) Are you deprecating VBA as a whole, even on Windows? If so, I find it quite acceptable that it’s not good business sense to write a brand new VBA interpreter only for backwards compatibility.
1a) If not, why not rewrite the interpreter in a modern way, as others have suggested?
2) Is anyone devoting brainpower to providing support for VBA’s replacement on the Mac?
3) If not, what are the odds that we’ll ever have the ability to run Win Office macros on the Mac again? I don’t care if it takes 3-5 years, honestly. It’s an essential feature, meaning you need to do it somehow, or people who need that feature will look elsewhere.
While Applescript is preferred on the Mac due to interoperability with other applications and with the system, and I’m glad you’re improving your AS support, I’m sick with dread about the lack of cross-platform compatibility. And I’m having a hard time accepting that it’s impossible, or even a 2 year job, even if you do have to write a new interpreter from scratch. From the sound of things, such a rewrite is overdue anyway.

Shaun – that is excellent news. If Microsoft isn’t willing to provide users with the compatibility that they need, then the customers will have to seek out solution providers that are responsive to their needs. This kind of callous disregard for customers won’t be forgotten.

I am a developer who uses Excel a lot on the PC. I have a macbook pro I would love to use for this task. I find kind of imperfect VBA for Office X, which runs in Rosetta, and I can live with this. I don’t think my bank is going to jump on the mac bandwagon anytime soon.
If it came down to adding features, what I would like to see is a very easy way to plunk in C++ code. I use the Excel SDK for windows. I make a DLL, rename it XLL and make sure there are a few functions that register my special functions. Beautifully simple. Sure I have to use C style APIs, no big problem for me.
If you document something similar for Excel/Mac I will completely forgive you for killing VBA. Indeed, I will rush out to buy the new version. Remember though, it has to be easy and ideally you should give a wealth of “Hello World” examples like the circumference calculation in the SDK book. The examples should be compilable with a minimum of magic binary pixie dust, and the Add-in should be add-able via the Tools, Add-In menu.

I applaud your open and frank comments – something we never get from the big software corporations.
I also agree with your decision, even though ideally I would like the best of both worlds.

Forgive me if I got the wrong impression from the article, but it seems that in the document, VB scripts are saved as what you described as, “kind of like Java [bytecode], but not exactly the same” rather than plain text in the document. Furthermore, VBE, which takes this “mostly machine-independent” code and displays it as plain text for editing, is mostly compatible with GCC, at least to the point where it is possible to port to XCode.
Now, if I got that all right, what I don’t understand is why VBA has to compile the opcode into assembly code. You already have VBE parsing the code to a certain degree, and compiling is not always the only answer. It seems to me that building an interpreter or a translator (to e.g. Applescript) instead of a compiler would be markedly less work. (It seems like many people have suggested this in the comments since last I saw this article.) Yes, you’d have to pretty much rewrite VBA from scratch. You could possibly use the same parsing code in VBE as the basis of VBA (depending on the code, which I am completely unfamiliar with).
In the long run, it would certainly be a greater investment than straight porting. And speed would definitely take a hit on execution. However, I have not had to deal with any macros where speed was ever a problem, even on older computers. And I definitely think that VB support makes or breaks the purchase of office for more people than you think.
I work in a tech support department at a University, and strangely enough, we get a lot of people coming in thinking we’re handing out free licenses to Microsoft products. Considering that these are mostly students where cash is tight, they don’t want to pay the full price for Office suites. I do tell them about alternatives (e.g., Open Office, Abiword), and it always comes down to whether they need VB support. Most College students just need something to type papers on, and so go for the free alternatives. Most of them didn’t know that there was anything besides Office. Business students and a few others need VB support, and currently their only option is to purchase Office. Business Administration 101 here uses an Excel worksheet with copious VB, and the class counts towards general education, making it very popular. Many students purchase Office just for that class. If the VBA support in Open Office proves capable of running the worksheet for that class, I’ll be forced to recommend that instead.
At the Office, I have Office 2004 installed on my Mac to fill out my time sheet every month, as well as a few other macros I have to deal with. Although you mention that many features have not been ported to VB on the Mac from the Windows side, I have never had a problem using Office 2004. In my experience from the different jobs I’ve held, the majority of macros were written in a time when solutions were less abundant and developers were more expensive. That is, they were written mostly in the mid-1990s. Having slightly outdated VB support hasn’t been that critical, but having it has been.
Having said that, I would urge you to just remember that the majority of Mac users are forced to work in a Windows world. Cross-platform compatibility is very important to many of us. Transitioning to a version of Office without VB support is bound to be more painful to more users than you imagine, and given that Office 2004 still works on Intel, I would expect that either it or Open Office will remain popular after the release of the next version.

“One problem with converting their VB code from this assembly compiler to C++ is that VB is a pretty hard language to parse.”
That is not the problem, because that would already be solved in the VBE part. It’s just rewriting VBA, and I would do that as an interpreter in C++, yes. Then you can always add some assembly later if it’s really necessary…

Oh, you mean you can’t port VB because it’s a piece of crap? Thought so.
Historical reasons for a bad codebase don’t count. When I pay for software upgrades, I expect the money to be spent in maintenance as well as new features.
What you’re saying to your customers is “Please buy an upgrade that is basically a downgrade, due to reasons you don’t understand, and which nobody is responsible for”. Good Luck.

I was thinking the same as Robert Cassidy. From the blog post:
“The AppleScript object model and the old VB object model for our apps are roughly equivalent, so apart from the syntactical differences, if you could do it in VB you can do it in AppleScript.”
And by providing an OSA component, anyone with a Windows/VBA background could use their VBA skills to extend every scriptable application on a Mac.

Just out of curiosity, difficulties in working with gcc are cited frequently.
What advantage would there be in working with the Intel compilers, since these will work with Xcode anyway? Intel already provides some tips for Xcode users (http://support.intel.com/support/performancetools/sb/CS-022350.htm)!

OpenOffice.org
Anyone who may have Xls files containing macros, if you would like to help Novell to improve support in OpenOffice.org, you can send them our way. Michael Meeks’ team at Novell is looking for macros that they can test in order to refine OOo’s support. Send to thaeger AT novell DOT com.
Thanks,
Ted

One other option seems to have been missed. Why not start from the VB specs, and reimplement it from scratch? All that are needed are an interpreter and an editor.
This approach surely sounds quicker if decent specs exist. They do exist, don’t they?

OpenOffice, IIRC, does have support for VB macros, and it will soon have support for the Microsoft XML file formats, as well as many other formats, open and closed and the increasingly important ODF formats.

If there was anything that will kill Office for Mac, this is it.
What is Excel without the power to run Enterprise custom code? Charts!
“Long rumored—or at least, assumed—to be in development, sources say Apple is not planning on positioning Charts as a competitor to Microsoft’s Excel, but rather as a more consumer-friendly spreadsheet application that can handle the needs of home users and small businesses but not pretend to execute any of the more advanced functions of Excel. ” -Think Secret
Why buy Excel?
To be honest, it is only Excel’s lack of VBA that has most users up in arms. I am an aerospace engineer, and using Excel as the GUI to running old fortran code using VBA is very common. I developed a workbook that takes code from many organizations and runs it all in seconds, all linked. This used to take weeks of schedule time the old way. What was great was I could compile the fortran modules for both Mac and PC and the same Excel file would work for both systems. Can I do this with the new version? I just need the Excel controls to work the same between platforms and the ability to call the code modules (custom functions included). If I can’t do that with the new Excel on Mac, I will spend less money elsewhere for the future VBA support and keep my old version under Rosetta for now.
By canceling the VBA feature, you create a demand for it in a competitors product. I am sure they will use existing technologies for JIT compilers, etc. and be cross platform to boot. Why re-invent the wheel there?
You need to have a 64-bit solution at some point. Get some resources from the windows side to work on the solution NOW that is cross platform, 64 bit compatible. Then you can focus your resourses on the GUI side. This also makes the VBA identical as you’re porting the windows intel code – an actual feature upgrade over Mac Office 2004/2007!
Never take a problem in an area as an excuse to create another problem. That is a trap people fall into to justify a bad decision. Fix ALL the problems, or eventually someone else will.
Promise us a completely cross-platform, easy-to-use solution to VBA in the following rev after 2007 . Everyone will understand it might take 2 years, but at least they will be more secure about the future.

Oh, please. Give me a break. M$ has smart people. People who, for example, can produce an Intel emulator for NT running on Alpha. It’s just a compiler exercise.

Very good, informative post.  I always enjoy the behind-the-scenes stuff from big software developments.  I’m writing here from one of the plug-in stations at Apple’s WWDC, so very timely.
But it’s a really, really horrible thing.  Seriously.  As a Mac user I’d rather see you drop Office entirely than slowly strip the compatibility from its core.  I don’t subscribe to the conspiracy theorists who say this is Microsoft’s secret way of getting Mac users to switch to Windows.  Mac users have their opinion of Windows and switching isn’t going to happen.
If you really, really have to kill VBA, I have this as a recommendation – connect VBA with Applescript.
First, AppleScript SHOULD have the same abilities as VBA.  You already have hooks in there for VBA.  Just replace those calls with Applescript listeners/whatever.  You don’t have to worry about parsing a thing, just doing things you’re already doing now.
Ok, that’s unlikely given what you’ve written.  It’s worth a try.  So here’s a real solution:
First, add as much scriptability as you possibly can.  Most VBA scripts I’ve seen are pretty simple – switch the interface around based on a click or text input.  I’ll bet most of what I see could be done with AppleScript already, but nobody uses it since VBA is cross-platform thus more convenient in distribution.
Second, add some hooks into the VBA code that is already included within DOC/XLS/etc files.  Let AppleScript communicate with the VBA source code.  Someone (it should be Microsoft, but it won’t be) could write a VBA parser for AppleScript.  It won’t do everything VBA can do, but it doesn’t need to.  Throw that parser’s responsibility out to the Mac/open source community and bundle the result with Mac Office.
With that done, most VBA scripts people write – the really simple ones – would just run.  Over time, more and more would run.
The result would be as it should:
-Very Mac-like due to excellent Applescript support
-Very cross-platform due to the VBA/Applescript parser
And also:
-Much lower cost of development for Microsoft because you can still dump most of the archaic code
-Good karma
Thanks.

Very brave blog! Keep up the great work on the products. All I need to know is when the universal binary will be released so I can get the right speed out of this intel mac.
If you have a few idle developers now, you could consider developing an mac emulator for the xbox so I could play halo!

While the post makes clear that updating VBA for Intel/XCode is a pain, it seems that there are other possibilities:
1) Keep the VBA component PPC, run it through emulation.
2) Use an interpreter instead of a pseudo-JIT.
Either way, there are many people using Mac Office only because of compatibility with Win Office. As that compatibility shrinks, they’ll be looking elsewhere.

Thanks for the in-depth explanation. I had no doubt that this was a terribly difficult decision for you guys to make, and I thank you for trying your best to keep the Mac user community as happy as possible for as long as you have.

Robert Cassidy:
“Ok, maybe this is a stupid question, but if VBA and Applescript have similar object models, wouldn’t it be fairly straightforward to build a VBA OSA component and just embed that? OSA would take care of all of the bits that you need all that assembly for.”
OSA is just a mechanism for wrapping up existing scripting language interpreters as plug-in components. Applications can then use the OSA API to invoke OSA scripts without having to care about what language they’re written in. It’s a nice technology, but it won’t help here where the technical issue is compatibility. You can’t mix PPC and x86 code in the same process, so wrapping the existing VB engine as an OSA component gains you nothing.
Incidentally, I do imagine that the MBU will use the OSA to implement attachability in Word and Excel, allowing you to attach AppleScripts to application objects just as VB scripts currently are. But you’ll still have to write these scripts in AS or some other OSA-compliant language, which VB will never be.
Speculating here (I posted some similar thoughts on Rick Schaut’s blog earlier on): One solution that could work (at least in theory) would be to decouple the VB-related code from the rest of the Office code and move it into a PPC-only agent (hidden background application), then use Mach messages/Apple events/whatever to let the app and agent communicate with one another via private interfaces. In practice though, separating the codebase and reconnecting it like that may well be very tricky to do given the age and complexity of the Office codebase – even the best architectures get gnarly and tangled with age. And since VBA is eventually going away of Office/Win too, this is a fair bit of work to do considering it’s still going to be thrown away in a few years. So I can’t see the MBU really wanting to do that when they could better spend that time on all the other features that users are demanding.
Another possibility: _If_ the VB and AE interfaces are sufficiently similar, one could take an existing cross-platform scripting language that can talk both COM and Apple events (e.g. Python) and create a couple of glue libraries that present a single standard API on both platforms. Users who want portable scripts could then write them in this language using this cross-platform API. Porting existing VB scripts could be made easier by providing a cross-compiler (e.g. Python has vb2Py, although I don’t know how good it is). I’m not familiar with the COM side of Office scripting myself, so couldn’t say if this one’s a realistic option or not. Might look into it tho’.

Amazing, MS can spend billions of dollars on R&D, yet they can’t support and upgrade their own existing software.
This is an obvious ploy to try and get people to leave MAC’s and go to PC’s.
Pathetic.

Why not make a VB to Applescript converter?
Since you said that the object models are so similar. Maybe there is some way to compile the vb source to applescript and then let the applescript compiler/executor (interpreter, whatever) do the other two of the three parts you identified.
I’d keep the source still VB so that you can save the document and have it go to some windows user who wants the script to work, but have a “magic” layer (:-)) that converts the VB source to applescript (or something like that).
Anyway, just a thought.

Seems to me that if reduced functionality is what we are to expect for Office:Mac then Microsoft should also include a licensed copy of Office:Windows in the box for us to run when needed. Why pay twice for the “same” suite to get the job done?
I wish that I were kidding about this, but I’m afraid it is the only plausible solution unless the MBU scraps this dinosaur code and re-implements from scratch using the latest Win version source as a functional model. This way, the code can be written using modern techniques in an appropriate manner. In the end the maintenance is probably worse than a fresh implementation.
Furthermore, if the MBU cannot handle this on its own (manpower/expertise/lack of will) I’m sure that there are several Mac development companies (OMNI? Real Software?) who could take the ball and run with it. Subcontract it!

Let’s just put this very bluntly – this decision and the current strategy is NOT ACCEPTABLE.
Mac users deserve an Office suite that is wholly compatible and feature equal to Office on Windows. Why? Because we paid good money for it and if you aren’t going to provide the same functionality, then either lower the price or start thinking really hard about how a sudden upsurge in Open Office users would sound to upper management. Really, if MacOffice is just an expensive productivity suite that only offers so so compatibility, then the prospect of free productivity suites becomes much more enticing.
Bring out the Outlook for Mac code, start porting the WinOffice suite with a Mac interface and get it over with. This pig that you keep slapping makeup on is dead!

1) I don’t understand these claims of “exit strategy”. Why would Microsoft need an “exit strategy” out of Office for Mac? If they wanted to stop supporting the platform, they would just stop supporting the platform, no “strategy” needed.
2) While there is no doubt that OpenOffice and other free office suites are becoming better and more popular, I do not follow the logic of people who keep bringing it up in their comments. MacBU is making this decision in order to *better* support the vast majority of their customers, i.e. non-enterprise customers. Claiming that removing VBA will drive these average consumers in droves to OpenOffice just doesn’t follow.

BTW — it’s staggering how many replies above me are ignoring all the irrefutable logic in the blog.

Maybe it’s time for a Microsoft endorsed version of .Net Framework 2.0 for MacOS X, since that’s the direction Windows and WinOffice is going.
It won’t help all the VBA people – but it will at least get MacOffice aligned for compatibility in the future, rather than just tossing any attempt at it to the wind.

I dated a woman long ago who had a pithy response whenever I would explain why I was too busy to see her: “You make time for what’s important to you.”
While your explanation is well written, and you say that compatibility with Win Office is one of Mac Office’s two “pillars,” face it: it’s not important to you.
The woman, of course, was right: she wasn’t that important to me. I had not been honest with myself or her. She also thought I was making a big mistake when I called the whole thing off.
You are making a big mistake or you are being disingenuous. Nobody is complaining about Mac Office not being Mac-like anymore–just that it’s slow and buggy. Do you actually think incorporating these “Apple tools and technologies to be more ‘Mac-like’” is going to sell more units than a rock-solid, WinOffice-compatible product running natively quick on Intel? (A guy can dream…) Do you honestly think Mac users are going to plunk down $400 for a Mac-like version of Word Pad and a My-First-Spreadsheet with hooks to iPhoto? There is no market for such a product. We use Mac Office for its compatibility with WinOffice.
You’re either not being honest with yourself or us.
If Mac Office is really important to you, you’ll do the right thing and code the VBA. Put the entire team on it. Just get it done. Deliver a product you can be proud of.

Has anyone thought of not upgrading? What great improvements have there been in Mac Office X since the original release for (was it) OS X 10.2.x? I’m still running the original release of Mac Office X on OS X 10.4.7 and it works fine.

First folks don’t panic. Is there any need to upgrade machines so quickly? The solutions you have will work on your current machine and will continue to do so for many years. I still do most of my productive work on a 7600 using Hypercard! Whilst I think the decision to drop VB support is short sighted and will lose customers aren’t we in danger of putting too much blame on MacBU? Surely a large part of the problem has been created by Apple decisions to change operating systems and chipsets whilst at the same time dump backwards compatability as fast as possible. These decisions have had an enormous impact on many of the collegues I have in research and education. We are time poor, and the cost of reprogramming many of the customised basic and essential research tools we use is beginning to far outweigh the ease of use, reliability and functionality the mac originally offered. I still do much of my research in OS9 and have customised programs written using CodeWarrior & Hypercard. These will work and can be expanded for many years yet. Although I bought a G4 mac to play civilaztion 3 and for iphoto, I will be following my university department and entirely shifting to windows when this machine expires. Lack of backwards compatibility and the cost of trying to promote the use of macs in a windows world has put the costs of supporting macs in an educational environment as far too high.
In short direct some vitriol towards Apple, not MacBU.
As regards Hypercard, how about a decent clone MacBU it would still be a killer app! All the wannabe successors including revolution have miserably failed to emulate its ease of use and elegence.

Many comments have suggested running VBA in Rosetta and the rest of Office as native Intel. This is not possible because Rosetta can’t translate only one part of the app – the whole process needs to be PowerPC. (For this reason, Rosetta doesn’t work on plug-ins such as OS X screen saver modules.)
It might be possible to run VBA as an entirely separate PowerPC process that communicates with the Intel-native Office apps using Mach ports or some other interprocess mechanism. But that would also be an enormous re-engineering effort, as every call to/from VBA would need some cumbersome wrapper.

Guess I won’t worry about getting a UB version of Office… I use Pages for my personal stuff anyways.

Our MathType product is the full-featured version of the Equation Editor (EE) we license to Microsoft for both Win and Mac Office. A large chunk of its additional functionality over EE comes in the form of menu and toolbar commands in Word to do thngs like equation numbering and reformatting and export to HTML+MathML. This is all implemented in VBA so we and our customers were unhappy to learn that it is being ditched. We will be letting our customers know about this so they can make an informed decision whether to upgrade to Office 12.
If there was a one-to-one implementation of the Word object model accessible via AppleScript, it would give us a way out. It would still be a lot of work to convert but at least it would be doable. Of course, it would also have to support execution of these scripts via added toolbar icons and menu items. Please consider it.
Paul Topping
Design Science, Inc.
http://www.dessci.com

I’m curious as to why you didn’t discuss virtual machines. It seems that developing a virtual machine using the standard tools for such things would make relatively short work of the execution engine.
This still leaves Forms and the object model, but perhaps the time frame for that work would become much more reasonable.

These have been great posts, I always enjoy reading about the gory details behind the apps I use. There have already been a ton of unworkable suggestions, so I figured I might as well add mine. Since it seems OpenOffice is close to having VBA support and is LGPL licensed, what if you guys looked into adapting their VBA code into a library that Mac Office could link to? I’m sure that the OpenOffice community (and Novell) would appreciate the patches that would come out of your effort, and it might be a ‘cheaper’ way to implement VBA. I’m sure it would be all over slashdot.
Like I said though, I imagine it would be unworkable, and not that much better than starting from scratch. I know that the OpenOffice codebase is fairly monolithic and I doubt their VBA implementation is nearly modular/portable enough to be of use. Maybe it could work though… modifying their interpreter to send Apple Events to Mac Office or somesuch. I guess that would still leave a lot of unsolved issues even if it were possible though.

Dependable, cross-platform compatability will in effect be dead. All I can say is thank goodness for the Intel Macs and Parallels. As a consultant who would prefer to use a Mac but needs to work with many corporate clients standardized on Windows, I will just be forced (as much as it will hurt) to keep a Windows VM running and make sure that any docs and spreadsheets that need to be exchanged with those clients are created and modified in Windows. Yuck!

Thank you for this behind the scene explanation. As a developer, I understand the technical chalenge of porting VBA to Intel. But as a user of Excel, I also understand that a majority of Excel workbooks contains VBA macro and so it is a huge losse for Office user and for the Mac platform.
Like Frederik Slijkerman in his two posts, I was ask to myself if you have explore the idea of parsing the VBA opcode with a VM written in C++. Having written several, It doesn’t seem huge job compare to written a JIT compiler. I’s more easy to debug and stabilize and also to port to several platform.
It’s the approach choose by OpenOffice (which has a Basic implementation but a different Object model than MS Office).
Concerning performance problem, it seems that today we don’t the need of a JIT compiler for VBA scripts. Machines are way faster than ten years ago.
In my job, I face the same problem as you: dealing with a old product (a development environment with a form editor, a language and a lot of assembly code). We choose another way to ports applications written with it: transcoding everything in Java. This implied rewritten old C code in Java. In fact, despite the higher level of abstraction, the execution was really fast). Quite usable.
And it was a great plus for the support team as it was easier to maintain a modern and well design code than an old and hack one…
The support of VBA could be supply in subsequent release of Office 12. This way, the users that need the most the VBA part of the compatibility would have a temporary solution: Office 2004 in Rosetta and a long term solution.
For now, they have no more solution… and has Mac users are not the most numerous, if they can’t execute important corporate Excel sheet, they will be forced to leave the platform or use Parallels and Office for Windows…

Matt said “It seems the responses are grouped into those from developers (who are understanding), and those from enterprise customers who, of all people, should understand economic reasons for not going ahead with VB support”
I don’t find this at all surprising. Developers have two reasons for being sympathetic. First, they acknowledge that the problem is difficult. Second, the solution chosen by Microsoft potentially means more work for them rewriting existing applications. Who wouldn’t be pleased?
Well the answer to that question is the second group – the enterprise customers who will have to pay for those rewrites. Microsoft is saving itself effort and money by passing the rewrite problem on to its customers. Those customers can of course avoid those rewrite expenses altogether by neglecting to upgrade to the latest version of Office. It will be interesting to see whether the resulting loss of revenue leaves Microsoft ahead on balance.

There are those for whom compatibility is the only reason to use MS Office. What happens to them if said compatibility breaks? Their only impetus to use Office is gone and they find something else.
Ya really gotta face facts here: most Mac office users don’t use office because they love it or it’s the best deal around: they use it for compatibility reasons. Also, lots of businesses only tolerate Macs as long as Mac Office can read files created by Windows Office, and there’s always some gnarled binary file that TextEdit won’t open, or a graph or two that only Word can view. It’s all about compatibility here.
If this compatibility begins to break, then two things will happen: businesses will insist upon Windows simply so their business works, and those using Office exclusively for compatibility will turn elsewhere, plain and simple.
I understand that Mac-Win compatibility and Mac-like behavior are your two overrriding concerns, but there are some things that affect one more then the other. In the case of VB, compatibility is key, and no amount of Mac-like prettiness will persuade those forced to change their software, skill set, or even employment as a result of the decision to remove what allows this product to exist in many markets to begin with.
Suck it up. You wrote bad code in the 90s. Now fix it. Adobe did the same thing, which is why CS is still PPC only. They even said so–they’ve still got 68K code in their software. Fixing this mess will take time, skill, innovation, and motivation. Does the MBU have them?

Sad but true: The MacBU at Microsoft does not understand their main product nor their customers. Do they really believe that there are any other reasons than cross platform and backward compatability to buy and use MS Office?
VB is the not another it is the essential feature of MS Office. Without VB I can use any other app that can open or import plain excel docs. Why should I bother to buy MS Office?
But wait, they simply can not be that ignorant not even at MS. So what is the real reason? They want us to switch to Windows and the Windows version of Office. But this won’t work either. I will never run Windows on my Mac and I surely won’t buy a PC. So, after 10 years its good bye MS. Now I learned my lesson and will never buy anything from this company. No software no hardware no books.

Enterprise customers’ anger is just another illustration how much they hate Macs and look for ANY reason to get rid of them. “Mac shops” where IT guys actually use Macs themselves would not have much problem with AppleScript, why would they? IT guys running PCs should stop wining and kick Macs out. That’s really what they are after, anyway.
I’m sure MacBU has the numbers to back the decision up. There’s no way the majority of consumer users doesn’t have Word / Excel on their computers. Too many incoming documents from PC users with MS Office pre-installed. Too many Word documents hanging on websites. No to mention there are folks that still like Entourage over Apple Mail (though I’m not one of them).
Thumbs up on the post, I’m not the biggest MacBU software user out there, but I have a lot of respect for you guys.

And in the long term, VBA will be replaced by a .NET based version anyway and so for the next version after the next version, which will be presumably be Intel-only, how about porting the CLR to the Mac.

Can we have a basic C++ api, well documented, for adding our own spreadsheet functions. The Excel 97 SDK is very easy to use in Win32 land.

“VBA is basically a compiler that emits code at runtime” – so, it’s an interpreter? That’s hardly an unsolved problem. I agree you wouldn’t want to touch the existing assembly code from either code base. I guess the other option is a language translator – maybe you could implement the opcodes in something like javascript (for which you already have a MacBU virtual machine from your explorer code…)
The forms stuff on the other hand sounds like a developers nightmare. I’m a developer and I feel your pain!
Your arguments all make perfect sense as to why VBA won’t be in the next release of Mac Office. The only argument that makes sense about why you would not then re-introduce it in a future version to re-attain parity with Win Office is to help corporate IT departments stamp out those Mac outposts in marketing that they hate so much.
Further to someones previous comment about Word 6 – the current MacBU approach is SO much better. Mac Word 5.1 was honestly one of the best word processing applications ever. If I could use that on a current Mac with support for current file formats I would. Maybe put modern table handling in it, but that’s all.
Having said that, it makes me think. Those (misguided) Word 6 developers could make a Pcode interpreter work on both platforms with reasonable performance on very limited machines. VBA is surely a much simpler proposition?
That also makes me think. I just finished listening to an interview with Microsoft’s Bill Hilf about Open Source at Microsoft. If you are truly going to abandon it – why not publish the VBA specs and the Mac Office plugin specs and see if the Mac community doesn’t come up with a solution. Much like the Win Office team did with the ODF plugin (If you were able to put some money up like they did then that would be even better).

As a long time user of Mac Office 2004, I can say that I’m gald that MS Office is being ‘ported’ to Intel OS X. I depend on it and the compatibility with Office for Windows is pretty good. However, let me just say that I’m really looking forward to the new version compiled in XCode. PPC Office 2004 has never really felt like a native app. It is slow, choppy, and eats CPU when doing absolutely nothing, especially when in the background. The scrolling is even choppy and jumps from page to page as soon as I have graphics inserted and the word doc is more than a couple of MB (even on a G5). How hard could it be to fix the scrolling? As someone who is not a developer and doesn’t really know what he is talking about, PPC Office 2004 feels pretty much like universal firefox: looks and runs alright but definitelely doesn’t feel like a native cocoa app. While I understand the effort needed to port to XCode, hopefully the final product will be well worth it. And yes, the inclusion of OS X technologies like Automator is killer.

Any idea how many academic & scholarly writers “out there” use Word + EndNote? Nor have I; but I do know it’s at least 80% of those I know. Without VBA, EndNote is useless. Without EndNote, Word (for that user group) is useless. I would expect this inexplicable (despite your sterling efforts to explain it) decision will cost Microsoft and Thompson most of its customers in the next cycle.
See, what we have at the moment, on Intel Macs, is a situation where Word is slow as syrup and EndNote is struggling (has been for years). What we *will* have is a situation where Word is okay but EndNote is useless. I woud predict a slow but ineluctable migration to Mellel plus Bookends/Sente: already two first-rate combinations and ones which, I suspect, Microsoft have just given some considerable traction in this market.
The short summary is this: many only use Word because it works with Bookends. When that stops working, game over.

The loss of visual basic is a non-story to me. I have used Office since 98 and have become increasingly disenchanted with it. If MS has to dump a component of Office to make it better that’s great. In my opinion there are a lot of better word processors and presentation applications for the Mac than office. My only concern is a replacement for Excel. My biggest complaints with MS is that they won’t use, or give me the option to use, the features of OS X such as address book and iCal. I have to maintain a seperate address book and calendar if I want to use Entourage.

Why not write a VBA2Applescript translator ?
Release it as downloadable freebie for Mac and concentrate on Applescript support in Office 2007.

Well- my first question is, where is this information (dropping of VBA) generally available to the public? I have a huge WORD VBA-based application that I’ve had in distribution for 5 years (now at version 6) I can’t even save the template on an intel Mac, but searches of the Mactopia and MS support sites have turned up nothing. The FAQ section on intel Macs at Mactopia makes no mention of VBA, so that says something about MS’s opinion of how many people it might be important to. Unfortunately, for my clients, this will probably mean the abandoning of Macs, as it’s pretty hard to justify purchasing and maintaining two OSs for each machine.
Bill Spencer

Lack of Visual Basic in any version of Excel basically makes it useless to me. I have access to Excel on both Macs and Windows PCs. I do my work on a Mac because Windows just feels wrong to me. I don’t like sitting at a Windows machine. However, the rest of my company and our customers almost universally use Windows. I have developed some spreadsheet forms with very complex Visual Basic scripts. These are sent to our customers who must run them on the Windows version of Excel. Having different scripting languages on the Windows and Mac versions of Excel basically makes them separate and incompatible applications as far as I am concerned. I would frankly prefer to develop Applescripts but it is not an option. Instead of going further down the Excel path this decision by the Microsoft will make me convert the Excel spreadsheet that I use to collect information from customers to web based database methods instead. It’s been years since I’ve used Filemaker Pro. Time to get a new copy?

Great read. My gut feelign tells me that someone at the top of the Microsoft food chain decided that it is time to kill Apple, the iPod, and anything that will make Apple a continued thorn in their side.
Won’t work though. Stay tuned.

well, for me thats saying goodbye to office than. Excell is my real need, and you just killed it.

I’m sure there is a better way. Instead of re-writing the Windows code to conform to Apple ABI, just make a wrapper that converts one type of call to the other. I mean sheesh, people have made Windows programs run on Linux for goodness sake. And instead of hand converting MASM to NASM, write a tool to do it or hack NASM. I mean, I used to work for a company that executed the exact same Intel binary code on three different OSes, DOS, and two flavours of Unix. How? By writing a small custom loader that loaded it into memory with differing shared libraries linked at runtime. There are so many ways to skin this cat, and a company with the broad technical skills of of Microsoft should be able to figure it out.

I feel compelled to point out that if any of my programmers came up with a design like the one you describe, I would have them fired on the spot.
How long can microsoft go on just putting out fires like this?

Joseph Blietmann, STFU!!

Well, I use macros in Excel all the time. In fact, that functionality is the only thing that has kept me tied to Excel. I’ve been very curious to at least try the OpenOffice solutions and now I see no reason not to.
Secondly, I understand that porting VB would be a lot of work. Unfortunately, the decision that your team has made is pretty much the same as: “Hey, let’s take the bold, underline, and italic functions out.” Sometimes things just have to be there regardless of the work and cost. For me and thousands of other Mac users, VBA is one of those things.
Disappointing to say the least.

I expect in the next few years you’ll be able to ALT+TAB over
between Windows and OSX, perhaps in Leopard, or in a post-leopard
system once Intel and Cupertino get their collective heads round hypervisors.
surely will happen in the next two to three years.
If you’re M$, why develop for two platforms? You can sell (licenses for)
Windows XP/Vista AND Office PC to a Mac that dual-boots or runs a hypervisor,
but you’d only get one sale for a Office ‘Mac Edition’ that runs Aqua / Quartz.
In 1996 it probably was necessary to compile into assembler on the fly and do all sorts of nifty tricks for performance reasons, (in 2006 CPUs, disc and RAM can tolerate a less efficient re-implementation) but the blog makes clear that putting VBA on Intel macs would require a year or more to write, quality assure and make stable if MS did it in house, or it would require a buy-out or collaboration with a third party such as REALbasic. Either way it’s not going to be immediate.
There’d be only a limited opportunity to recoup that expenditure in sales before the underlying technology made the duplicate work irrelevant, so it makes sense to bandage things as best possible.

Amazing. We’ve arrived at version 11 of MS-Office with full backward compatibility (mostly full anyway). We’ve had cross-platform compatibility since at least 1998. Compatibility was always a core MS tenet. It’s really a slap in the face to scientists, educators, students, and business people who have been loyal to the Mac BU. I think there’s nothing wrong with making Office more Mac-like. But not by cutting out functionality that has existed for the past 2-3 versions.
Perhaps the “correct” answer here will be some combination of porting AppleScript to OSA for Windows, opening up Office 2004’s VBA code to the OSS community, and creating a more open platform out of Office for the Mac.

What a whitewash…
It’s amazing to me that M$ can produce 11 generations of VBA enabled Office releases and not be able to do the next generation because “GCC is picky”. I love how the MacBU guys are actually justifying throwing away their jobs iwth a straight face.
Ben

I have serious problems with your explanation.
As far as I understand, VBA is a scripting language, the only thing you HAVE to provide is a faithfull converter/interpreter and the featureset.
The fact that the old VBA represented braindead coding, should not in any way excuse that you shuold be unable to implement the featureset in a more robust way today. Yes, it would be a big job, it would maybe have to wait to AFTER the lauch og Office -08, but there should be a number of ways to make a working solution , including spawning VBA out as standalone application on Rosetta or some trick using VPC and teh Office-07 codebase…
Mac Office is the key component for me to use a to enterprise. And the REASON for it beeing key, is VBA. I can use Openoffice and Pages and any spreadsheet kan replace Office as long as it is able to work with VBA.
A couple of years ago, Exchange exploded in enterprise. Since the internet features of Exchange at that time was a securityhole the size of a supertanker, noe proper exchange administrator wanted to run them. At this exact moment MBU choose to remove the Outlook klient and replace it with a internet protocoll only version.
Now Exchange works somwhat better and exchange admins slowly start to accept imap access, and then we suddenly get hit with this!
Yes I know I sound paranoid, but you have to admit that I have a pretty good Reason.
So please, please for the love of God, save me from the hell of Windows. I’ve been there, I tested Vista, I do NOT want to go back there again.
Get VBA working and put it in a servicepack!
(By the way, please break in at the exchange group and steal the exchange protocoll and implement it in Entourage. My Exchange Admin doesn’t trust you yet, )

I only learned today from MacFixit about the end of VBA support on the Mac. What terrible news! I cannot imagine any reason why I would upgrade from a Win-compatible version of Office to a Win-incompatible version.
Inter-platform compatibility is critical, and making Office more “Mac-like” is nothing more than nice. In fact, I confess to not knowing what it means to be more Mac-like, in spite of using the Office suite on Macs since 1988 and on Windows since 1993.
For years columnists like Walt Mossberg of WSJ have advised readers there is no issue in switching from PCs to Macs because of file compatibility in Office applications. In the future there will be a big caveat. Even if they don’t completely understand, people will be wary, as well they should be. In my own case, as it becomes time to replace our Macs, the lack of compatibility (and the lack of VBA functionality) will provide strong incentives to switch to PCs. At home we have both Macs and PCs, and use both with Office files from work that contain macros.
Is the problem that MS corporate won’t give the Mac BU resources to ensure VBA compatibility? If so, one wonders if the MS strategy re. the Mac is similar to its strategy re. Java: “Embrace it, extend it, and extinguish it.” I know that’s not your motivation, but as a Mac BU business decision, it just doesn’t make sense to me.
Thank you for going into detail about the difficulties of porting VBA to Mac-Intel. I certainly can’t comment on specifics or offer suggestions on how to do it, but you did convince me that it is very hard. Still, from my point of view, ensuring complete inter-platform compatibilty should be a higher priority than anything else, and is certainly more important than implementing new features. Even if MS didn’t invent spreadsheets, I’ve long believed Excel is the greatest software package ever developed. The business problem for MS is that it’s so great, that any improvements at this point are marginal, and to many, if not most users, the benefits tend to be offset by the investment of time in getting up to speed. Still, we usually upgrade in order to have the latest, greatest version. However, unless and until you reverse the VBA decision, this time there will be a huge penalty for upgrading, and it is simply inconceivable to me that whatever the possible improvements, they would outweigh the giant negative, even if the upgrade were free.

Sounds to me like the real problem is that VBA has become such a kludgy house of cards (which does happens after something like 20? years of ongoing development), that you folks really need to do what Microsoft did with Windows NT: scrap the whole damned thing and start over using modern programming tools to generate maintainable code. That’s substantially easier than trying to fix what barely works and what nobody really understands anymore (witness your comment about no longer having the VBA 97 source code).
Your comments about the quantity of assembly code still living in VBA are a sign of outdated programming approaches: modern hardware is amply fast to run VBA without such tweaks. Sure, it’s not so fast, but at least it works and can be maintained — when it stops working, at least you’ll know why. Isn’t it time you stopped hacking assembly code and left that to the compiler developers?
I’m encouraged that you’re making Word more Applescriptable, and so long as you give us hooks into all the interface features (menu items and dialog box widgets), we shouldn’t have any impossible difficulties in automating Word. The lack of cross-platform compatibility will be a real problem for some of us — a deal killer for some. Have you considered asking Apple how hard it would be to port Applescript to Windows? Look… it runs already on an Intel chip, so how hard could it be to tie it directly into Word under Windows? Seriously, though, why not ask? Apple has been keeping OS X parallel on Intel and PowerPC chips for many years now, and maybe they have an Intel-based Applescript you could license for this purpose. You won’t know until you ask, and don’t forget: Apple knows how important Office is to Mac users. They’d have a strong incentive to cooperate on this with you.
I’m also encouraged that you understand the importance of bug fixes, but am disappointed that you folks are so hung up on adding new features to Word (e.g., that damned “ribbon”) while breaking things that worked just fine already (menus) that you’re ignoring longstanding bugs that everyone knows about — such as the fact that autonumbering hasn’t worked since roughly Word 6, and that you could fix it in 5 minutes using the {SEQ} code approach that is well known in the writing community and well supported by all versions of Word that I’m familiar with. Then there’s the persistent bug in which revision tracking forgets the user identity, meaning that you can’t edit your own edits without having these tracked as changes by another editor. That’s a cross-platform bug, by the way — it’s bitten me and many others in several versions of Word on both platforms.
I don’t know how much “pull” you have in saying how things are done, but I do encourage you to think about some of the things I’ve said. You have some idea of the grief you’re causing your community of users. Use that to help make Microsoft more responsive to real user needs and less driven by the need to sell new versions. To be blunt, many of us who are still using older versions of Word are doing so because we’ve grown accustomed to the bugs in those versions and aren’t willing to sacrifice our hard-won skills and tools to upgrade to new versions that don’t fix the old bugs and that break features we rely on. If you’re going to pull a trick like the ribbon, at least have the courtesy to leave the old interface available for those of us who have mastered this. You did that in Word XP and 2003, and I encourage you to keep doing that in the future.
And while I’ve got your attention? I’m not going to upgrade for new features of questionable value, and irrespective of what your market research tells you, neither are many other readers. I was vastly amused by your advertising campaign comparing users of Office 97 to dinosaurs. Did your marketeers ever stop to ask themselves why we dinosaurs don’t upgrade? Give us a new version that fixes all the old bugs, that doesn’t eliminate our old tools and obsolete our old ways of working, and hold off on the features and I’ll upgrade in a second. I bet I’m not alone either!
All bitching aside, I _live_ in Word, and can’t imagine working without it. I wouldn’t take the time to bitch if I didn’t care.

I am going to buy a mac, stands-whether?
I wait for advice. In advance thanks.

Gosh! This post just made me mad as it doesn’t change the reality which will be created from this inconceivable decision.
VBA is still a core part in my business and the fact that I can write VBA macro on my Mac is the most important excuse why I can use Mac in my company where most of the people use Windows. This decision simply suggests me to buy Parallel, Vista and Office on Windows instead of new Office on Mac – something I personally hate to do.
I don’t make any comments on technical difficulty of importing VBA to new Office on Mac. I definitely prefer waiting for two or three more yeas for the new Office on Mac with VBA to waiting for a year for the new Office without VBA. Reducing crossplatformability is simply nonsense.

Well… I was waiting to see what handicap would be introduced with the new Mac Office suite. Now we know. I’m afraid this is a deal breaker for me. The only reason I use Microsoft office is to work with others in my organization (who use VB extensively). Looks like Parallels with vista for me in the future and iWork for most of my day-to-day stuff that doesn’t require cross-platforming…

I think the fundamental problem is that your basic premises are skewed. You say, “Mac Office has two primary driving requirements:
1. it must be as Mac-like as possible, use Mac features, and take advantage of the Mac operating system, and
2. it must be as compatible with Win Office as possible, and share as many features and commonalities as it can.”
In fact, the only requirement that counts AT ALL is #2. Macs have always had excellent word processors and spreadsheets and presentation packages — programs that many Mac users prefer over MS-Office. The ONLY reason that MS-Office has had an indispensable position on the Mac is because of its cross-platform compatibility — a compatibility, by the way, that is actually rather poor compared to what has been achieved by OpenOffice on all of the platforms that it supports.
Make the Mac product look and operate EXACTLY like the MS-Windows product and it will have better compatibility. More companies will be willing to use it because it will cause less trouble for their MS-Windows users. The fact that it won’t be a “Mac app” is actually irrelevant. No one buys MS-Office because it’s such a great Mac app; they buy it because they need to be able to exchange files (and macros) with MS-Windows users.
As an aside, if all of Microsoft followed clean programming practices in the first place, your code would be more portable, *and* more secure, as well as easier to update.

Hi,
I want to know if it is possible to run the windows version of MS Office on an intel based apple mac.
This is because i’m contemplating purchasing a macbook, but already have office from my other windows notebook and would prefer using that than purchasing the office which is for macs.
Thanks in advance.
ciao
Sisco

Oy,
Every time I’m about to give Microsoft a second chance, they go and pull some stunt like this. From the sounds of this article it would seem that Microsoft is doing exactly as it appears- repeatedly reskinning the same code with no real reason to upgrade and now for me no reason to purchase at all. Every couple of years folks are charged $500 per user, just for the right to make word documents, a spreadsheets or two and some slide projections?
Mix up the format and bam… it must be a better file, but as this article clearly shows, its all built on dated technology. Well, this announcement synched it for me. I was going to give Mac Office a try for development since I can code in VB, but I’ll just pitch the VB altogether. So, in a way this works out for everyone. I have less to worry about supporting and Microsoft has less to worry about selling.

I’m just a home-using lurker breaking in on a conversation I barely understand, but it’s very educational. As a home user with pretty simple needs, I begin to see why MS software is so hugely bloated and hugely expensive (and therefore so hugely popular on the Gnutella circuit). MS creates this kind of software to satisfy the requirements of its large corporate customers, and then turns around and markets it as consumerware as well, expecting average consumers to pay for the development of features they do not want, need, or understand. So I guess when I pay the huge price for MS Office, I am in effect being expected to help subsidize Corporate America. No thanks. From now on it’s Open Office or iWorks for me!

Good decision which signs the MacBU cohrence with its target platform.
To appease VB writers they have to know their switch will be easer as ever so great is now AppleScript, stable, finely documented, enough speed, very well integrated with Xcode / Interface Builder, and so on.
Thanks for explanation. Continue to produice this so mac style office suite as Win users continue to be jealous of 😉
It does not remove anynothing to other suites than it’s needed to salute, free or not, mac, win or xplate based.

Despite your explanation, it is not just apparent that MS is preventing the Mac market from achieving a foothold in the enterprise market – it’s a REALITY. Let’s face the facts – the MacBU is a decent profit center for Microsoft. Mac Office easily is one of the best-selling apps for the Mac platform. The Mac community has stood behind it because of its outstanding cross-platform compatibility. Now you are ripping out one of the most important elements of that compatibility.
Regardless of the pain and suffering it will inflict on developers, MS has ripped the rug out from under us and potentially has forced most of us Mac users in the business community to run Windows on our Intel Macs and run Windows Office. Sorry, your explanation may be convincing to some, but not to all of us. Let’s face it – if MS really wanted to keep VBA functionality in Mac Office they would devote the resources to doing so. As in Jeff’s post above, MS INDEED is protecting its Windows turf. The MacBU blew it here. You guys MUST reconsider – otherwise most of us will be stuck in the Rosetta world of Office 2004 for a long time to come.
A pathetic excuse for a company that clearly wants Windows domination. Sorry but that’s the message Microsoft sends “the rest of us”.

Thanks for the info – but I am afraid that due to the heavy use of Office at my work (where we use Windows 2000), I probably won’t be upgrading to the next Mac Office. I simply by need will be forced to continue using Office 2004 or find an alternative. It is disappointing that MBU did not think of this as a high enough priority. I honestly believe that sales of the next Mac Office will be lower than the current one.
With the rise in home purchases (albeit a small one) of Macs, the need for cross-platform issues to be as transparent as possible will be even greater. I know this will be a huge issue for me – sorry to see MBU making this (bad) decision.

I’m coming late to this discussion, but the simple bottom line for me is that, particularly over the last 2-3 years, most of the documents I receive (Word or Excel, and maybe even PowerPoint), have macros in them.
Dropping support for VB will likely make these documents unreadable in newer versions of Office. So there’ll be no incentive for me to upgrade to Mac office, leaving me with two choices Open Office/Neo Office, or running a later version of Windows Office under some sort of virtualization software.
Neither alternative bodes well for the MacBU.
The other point I’ll make is, despite the -superior- job the MacBU does ‘mac-ifying’ MS Office, I’m still really upset at the chronic bugs I run into that never get fixed. #1 on that list is double-clicking a MS Word document, selecting Print, causing MS Word to immediately crash.
dave

RIP Office Mac.
I’ll buy an extra couple copies of Office 2004 to tide over my organization for any potential needs in the next couple years while I investigate migration alternatives — although such alternatives are unlikely to involve Windows or MS Office, aside from maybe one document recovery and conversion machine (as it slowly become impractical to continue using 2004). Without cross-platform scripting compatibility there’s little reason for me to stick with Office.
Office 2004: the last useful version of Office for Mac. Kind of a shame to throw away an otherwise reasonably good product line, and it sure throws a spanner in the works for me, but I guess the world has to move on. Oh well. RIP.

Late to discussion, but others have hinted at making VB for Office follow similar model as GCC — a frontend editor/compiler which translates into a bytecode or intermediate language capable of interpreter execution or compilation through Xcode/GCC [maybe Java, bringing a host of new objects which could be embedded in documents?]
Scanning the post above, seems VBA is struggling with legacy approach (probably dating to Win3? and slow cpu’s). Amazing such a valued tool could create a major headache for the big “M” ?
To compare stories, years ago when enterprise computing introduced 4GL’s for business queries, tons of reports and queries were written; the major issue again became compatibility and converting those reports and queries to the latest technology–SQL, Access or Excel spreadsheets.
Does this merry-go-round ever stop?

Seems people are under the impression Microsoft is somehow obligated to do a “proper” full version of Office.
Thats just not true. They almost certainly could make more money using the MacBU developers for other jobs, they just keep it going for goodwill and to be seen as playing nicely with competitors.
Plenty of platforms have seen major applications just dropped because they are too expensive. For example Lotus Notes only supports Windows for a client now despite thousands of businesses using it on other platforms. It could EASILY happen to Mac Office.

Apple can get PowerPC code to run seamlessly on Intel chips

Seems people are under the impression Microsoft is somehow obligated to do a “proper” full version of Office.
Thats just not true. They almost certainly could make more money using the MacBU developers for other jobs, they just keep it going for goodwill and to be seen as playing nicely with competitors.
Plenty of platforms have seen major applications just dropped because they are too expensive. For example Lotus Notes only supports Windows for a client now despite thousands of businesses using it on other platforms. It could EASILY happen to Mac Office.