All MacBU

Saying goodbye to Visual Basic

Well, its been less than two days since the MacBU announced that Visual Basic is being removed from the next version of Mac Office. The news has created quite a firestorm on many Mac forums (I’ve been scanning MacNN, Ars Technica, and a few others) and I received some very strongly expressed opinions about it in comments on yesterday’s post. I’d like to take some time to express my own views and experiences on the removal of Mac VB.
I should clear up one misconception about how the VB removal affects existing macros that has been making the blog and comment rounds. The removal of VB means that existing macros in Office documents will be round-tripped across file open and save, but you will not be able to edit them and you will not be able to run them on the Mac. Even previously compiled macros will not execute, because they have been compiled to PowerPC code that conforms to an older binary interface.
I want to say right up front that the MacBU is very aware of the pain this decision will cause for users, consultants, and enterprise organizations. I’ve personally seen the phrases “apoplectic with rage” and “absolutely livid” in two emails that crossed my inbox. Some people made comments on my post yesterday that were expressly clear about how this decision would drive them to one of the free Open Office variants instead of buying Mac Office 12, and other posts in other forums made similar statements. I’m sure some people will indeed decide that lack of VB is an absolute deal-breaker and they will plan to use other software. I’m truly sorry if that is the case for you.
The MacBU did not make this decision lightly. I personally spent several weeks digging into the VB source code to identify and plan what work would have to be done to move it to Xcode and make it universal, and I had several long discussions with our product planning folks to help our group leadership weigh the costs of doing the VB port vs. the costs of not doing it. I’ll try to lead you through some of the analysis here.
From my perspective, 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.

(We’ve got other requirements and product visions, but as I see it, they really act to refine these two basic needs.) As you may imagine, these two goals are many times not perfectly aligned. In the worst cases, they may actually be diametrically opposed, and we have to wrestle with making the best decision we can, knowing full well that whichever way we go it will help some users and hurt others. This VB decision is one where we’re truly caught between the Mac rock and the Win Office hard place.
VB on the Mac exists for cross-platform compatibility. There is no other software on the Mac that also uses VB, so it doesn’t help Mac Office integrate with other workflows based purely on Apple solutions. Thus, any work we do on VB only serves to satisfy one of the two major requirements. Doing that work then means we have less developer time to continue to improve Mac Office’s use of Apple-specific technologies (or tools, such as Xcode.)
Let me describe for you some of the technical challenges that would be involved were we to try to port VB to Xcode and to the Intel platform. For those of you reading who are not developers, bear with me for a little bit. Hopefully you’ll at least get a sense of the scope of work even if you don’t quite follow the nitty-gritty details.
VB on the Mac is really three parts: VBE (the editor), VBA (the execution engine) and Forms (the buildable windows and controls you edit in VBE and see when running a macro.)
VBE is pretty standard C++ code. However, the code is generally very old — it was originally designed and written several years before I came to Microsoft in 1996. VBE contains the top-level parser that converts the text of a macro into a series of mostly machine-independent opcodes (kind of like Java bytecodes, but not exactly the same). Thus you can’t just hook an external text editor up to VBA, because of the upper-level dependency. The VBE code actually isn’t too hard to port to Intel, but it is tricky to port to Xcode/GCC because of the age of the code. As I mentioned in an earlier post, GCC is very picky about code meeting the current standards and the VBE code most certainly does not. That’s not to say the code is ‘bad,’ it was just designed and written long before current modern C++ standards.
VBA, on the other hand, is incredibly difficult to port to Intel. The execution engine basically runs through the previously mentioned opcodes and, well, executes them. The hard part is that ‘executing’ them doesn’t mean interpreting them, it means converting one or more at a time into a block of assembly generated at runtime that looks and behaves like a regular function that can be called directly by other normally compiled code. This is in essense ‘self-creating’ code, and VBA is constantly flushing the CPU’s code cache in order to mark these chunks of data as executable. VBA’s generated code must adhere to the Application Binary Interface of the host platform (historically PowerPC and the Code Fragment Manager). This means register allocation, stack alignment, parameter passing locations, etc. VBA is basically a compiler that emits code at runtime. It does so by running a large state machine that tracks PPC register usage, stack location, mapping between PPC registers and VB variables, etc and then concatenates large blocks of pre-generated assembly together. VBA subsequently tweaks the assembly bit-field by bit-field to do things like assign registers to each opcode, set branch addresses, and create transition vectors for all function calls. The templates are very PPC- and CFM-specific and the state machine is designed for architectures that allocate static stack frames and pass parameters by register, unlike Intel which has dynamic stack frames (you can push and pop data to/from the stack any time you want) and parameters are passed on the stack. So, for us to port this to Intel we’d have to rewrite the entire state machine and create brand-new templates of IA-32 code. That’s basically writing a rudimentary compiler almost from scratch (we’d at least have the initial parsing and machine-independent opcodes already done.) Again, this is all a design that long predates me or most of my peers in Mac Office, and is code that we inherited when we created the MacBU (i.e, none of us wrote it in the first place.) There’s nothing inherently bad about the code, it was just designed for the constraints of the day and that design simply doesn’t lend itself to being architecture-independent.
Some folks might ask why not just port the Win Office VBA over to the Mac? Well, VBA circa Win Office 97 (which is the closest Windows VBA to what we have on the Mac) doesn’t implement their execution engine this way at all. Instead, they have tens of thousands of lines of IA-32 assembly that directly implements all of the opcodes. That assembly does so according to the Windows Intel ABI, which is different from the Mac ABI in several important ways (the specifics of which are described here.) Also, the assembly is in MASM format which is close to but not the same as NASM as supported by GCC. So, we’d have to edit the source to be compilable by GCC, and scrub it line-by-line to find and adjust the parts that aren’t compliant with the Apple Intel ABI. We’d also end up with two completely different implementations of VBA (PPC state machine and Intel straight assembly) that we’d have to maintain and keep in sync. That would be horribly bug-prone.
Lastly, we have Forms. Forms is also C++, but is backed by several thousand lines of gnarly custom assembly. This assembly ‘allows’ the C++ code to swap object virtual function tables and individual member function pointers between objects on the fly, to essentially do very fast object morphing. To do so, the assembly has to have specific knowledge of aspects of the C++ compiler (vtable layout, implementation of ptrs-to-member-functions, etc) and has to work in lockstep with the compiler. I spent almost two weeks massaging this code to try to make it compatible with just the PPC Mach ABI, which is only slightly different from the PPC CFM ABI. Even after all that work, I still didn’t get it completely right and internal builds had some really bad stability problems. We also don’t even have the Win Office 97 Forms source code, so I was not able to compare our code to how it was implemented for Windows.
I just noted that the assembly has to work hand-in-hand with the normal C/C++ compiler. That wasn’t too much of a problem when we were using CodeWarrior, as the C++ compiler only changed in small ways every few years or so. With Xcode and GCC, my understanding is that Apple has to merge in all the changes that external developers commit to GCC, and we run the risk of GCC changing much more frequently. That might not be a problem in reality, but the risk is non-zero and we have to take that into account.
One final problem is that all of this custom assembly is currently PPC 32-bit, and even the corresponding Windows assembly is Intel 32-bit. If we ever want to make a 64-bit native version of Office, any work we might do to solve all of the above problems would have to be done all over again.
So, in short: VB has lots of code and assembly that specifically assumes it is running on a PPC with the Code Fragment Manager, and to re-do it for Intel would involve writing a rudimentary compiler and relying on private compiler implementations that are subject to change at any time.
Whew, that’s a lot of technical stuff. I hope it provides some idea of the scope of work we were facing. We estimated that it would take roughly two years to of development time to move it all over to Xcode and to Intel. That would mean two more years before the next version of Mac Office made its way to consumers. In the meantime, Leopard will ship and Mac Office 2004 would still be running in Rosetta. Win Office 2007 and the new XML file formats will be ever more common. All Mac Office users would still be stuck with the old formats, unable to share in or use the great expansion of capabilities these new file formats bring. During that time, we’d also not be adding any other items our users have asked for.
Beyond that, if we were to port VB over to Intel in those two years, what you’d end up with is VB for Mac just as it is today. It still wouldn’t be feature-comparable to VB in Win Office, and the object model in Mac Office would still not be the same as the one in Win Office. That means that your macros would still be restricted to the same set of compatible items as you have today. Over the last 10 years, the Win Office programming model has become very different from that of Mac Office. We’ve tried to keep the object models in sync for the features that we have ported from Win Office, but we haven’t ported everything.
So, given that the developer cost was huge, that the consumer cost due to the delay while we did the work was quite large, and that the end result would be no better than what we have today, we made the very difficult decision to invest our time and resources in the other pillar of Mac Office, namely taking advantage of Apple tools and technologies to be more ‘Mac-like’. We’ve continued to improve the AppleScriptability of our apps (many many bug fixes post-Office-2004) and as announced are looking into adding some Automator actions to the suite. We’ve completed the rest of our transition to Xcode and to Intel and are forging ahead with the rest of the product.
I think a common question might be ‘if the cost is so huge, why doesn’t Microsoft just devote more resources to the problem? They’ve got a ton of cash, right?’ Well, the real question is ‘what resources do you throw at the problem?’ We’ve been working very hard to hire a bunch of developers, but it has turned out to be quite difficult to fill our existing open headcount positions. As an example, I’ve had an open position on my own team for 9 of the last 12 months (it took 8 months to fill the slot when one developer moved from my team to another one in MacBU, and only last week did we hire someone to fill the slot vacated recently when another developer moved to a different team at Microsoft.) The question of how Microsoft allocates developer headcount and funding to MacBU is a separate topic of its own which hopefully I or some other MacBU blogger will tackle later. In any case, there’s no point in adding new headcount to the MacBU when we haven’t yet filled the positions we already have open.
I know that explaining all this doesn’t make the fact of VB’s death any easier for those users who currently depend on it. As I said at the beginning, we in the MacBU really are aware of the difficulties you face. Our product planners, program managers, developers, and testers are working to alleviate some of that pain. Many people have only a few simple macros they use, and I do want to point out that those macros will translate very easily into AppleScript. Even large macros can be rewritten in AppleScript, although that takes some time and definitely some knowledge scripting on the Mac. 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. While I can’t comment on any more specific feature work for Office 12, I’m sure we will be working closely with enterprise customers to help them address their concerns. We’ll be saying more about our scripting plans as we get closer to the product release for Office 12.
For those of you contemplating a switch to Open Office, I don’t know if Open Office has any support for VB macros or other OLE Automation technologies so I don’t know if you’ll be any better off from a cross-platform perspective. You probably can’t be worse-off except that Open Office certainly doesn’t support any of the Mac OS scripting technologies that Mac Office does support and in which we will continue to invest, nor will it (at least for a while yet) support the new XML-based file formats. If you do switch, we’ll miss you.
Many people have viewed this announcement by MacBU as a sign that we are out to screw the Mac community, or that we’re just looking for an exit strategy. We’re not. Most empatically, we’re not. This decision was agonizing. My manager even said he felt ‘sick about the impact on those who really rely on xplat [cross-platform] VB support, particularly in Excel where we see it the most.’ In my post yesterday, I said that I wasn’t so sad to see VB go. I said that from the perspective of a developer who’s worked to maintain the code for many years. However, there’s nothing good about removing a feature that many people rely on, except that it frees up resources for us to invest more heavily in other important areas. Due to the age of the code, VB has been a very large drain on our resources for a long time with relatively little return. A couple of months ago I wrote that I hoped my blog would help people trust the MacBU a little more. I can see that many of you are very mad about this decision; I do hope that my post today helps you see some of the issues behind the press release. We had to make a hard decision one way or the other, and this is how it turned out.
(Please read my next post and consider giving us specific actionable feedback. Thanks!)

221 replies on “Saying goodbye to Visual Basic”

Thank you for the excellent post. I was guessing that it was an economic decision based on technical complexity and its wonderful to see how much thought you put into this before deciding on the feature drop. Personally it’ll be annoying reworking some old vbscripts for office ’04 to the next version but I’d certainly rather have the next version of office much faster. Put another way I get a lot more complaints about the speed and memory use of Rosetta then I do any comments at all about vbscript.

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.

What’s happening to VBA in Windows Office? As I understand things (which is from a distance, and not very well 🙂 VB in Windows generally is being changed to running in the CLR, so it would make sense if VBA was going the same way.
If that’s true, then the whole existing execution “engine” will be getting thrown away anyway. Why not replace the Mac Office VB engine with the Win Office CLR-based one?

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.

Thanks for the detail: I said yesterday that even from your initial comments I could see why you’d drop VB but I didn’t appreciate the scale of the problem.
And I am reassured by your comments about AppleScript, too.
But could you just say one or two more things about that? I realise there’s a limit to what you can say before a product is released but very generally should I be expect to be able to record AppleScript the way I can now record macros? (I know there’s something in the core AppleScript about recording but the only app I tried to use it on fell apart so I’ve ignored it.)
And should I reasonably expect Word 2007’s AppleScript dictionary to let me do quite precise text manipulation?
If these are right, I cease to be so bothered about VB: I’ve only recently got into AppleScript but I like it.

[…] Ursprungligen skriven av bjelkeman Ett betydligt större problem är att de slutar att utveckla VB för Officer för Mac. Nu hamnar vi där igen, Office på PC är inte kompatibelt med Office på Mac. Detta kommer att vara ett hinder när man behöver använda sin Mac på jobbet. (Jag vet att det är förmodligen ett mindre macro virus hot, men ….)…lls.virtualpc/…m/710002440831 Erik Schwiebert ger lite bakgrundsfakta till beslutet i "Saying goodbye to Visual Basic". […]

I’d like to echo the sentiments above, Thank you very much for your well thought out post explaining the decision to drop VBA.
I do have a few questions though.
1.) Will users be able to purchase realbasic for use with Mac Offie 12?
2.) Please bear with me if this sounds stupid, but isn’t it possible to run your existing vba ppc code via Rosetta?
Mac Office 2004 is a CFM executable whereas the default executable format supported on the mac is Macho-O. Would that be a problem? You did say that the VBA code was extremely PPC specific and CFM specific. I’m assuming that Mac Office 12 would be moving to the new Macho-O format. While Rosetta could potentially sort out the PPC dependence, would leaving the VB code running in rosetta cause problems because of its CFM dependance?
3.) Do you reckon this to be the end of cross-platform scripting?

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?

OK, if the biggest an richest software company in the world is not able to code VB for Intel Macs, then work with REAL Software and license their REALbasic to build it into Mac Office. According to “The syntax REALbasic uses for Office Automation is very similar to Microsoft Visual Basic for Applications”.
Oh, and BTW: OpenOffice already supports the new OpenDocument XML file formats. I’m 100% sure, you won’t support them. Microsoft never supports open standards beyond marketing claims.
And about your call to trust Microsoft: Creative and others trusted you with your PlaysForSure stuff and got stabbed in the back by you and your Zune efforts…
Maybe I’ll trust you (and buy your product) if all localized versions of Mac Office support writing Japanese (with Ruby text) like Win Office does. Currently I don’t even have an alternative to OpenOffice on the Mac to write Japanese with furigana.

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.

Wanted to toss in a few notes as someone who supports multiple platforms, and has delt with VB in applications. First, VB is used heavily in our office platforms on the PC – as that’s what most of our users use on a normal basis. The majority of people that I know who use Mac’s are home users who use PC’s in the enterprise at work. SO, VB support going from PC to Mac isn’t exactly a requirement. It is however handy for those users who do such work from home, and as Mac’s make more appearances in enterprise arena’s, well, it’d definitely be handy.
SO, though VBA isn’t an option at this point, someday it would be nice to have. Will VBA make an appearance again at some later date? Perhaps through a rewrite or some other method that is more manageable? At the very least, I do say SOME scripting supoprt is required. Whether this is done through AppleScript or Automator, I’d think something is needed. Can AppleScript support allow you to do all the things (or at least most) that VB can do? Can you document this well (a major issue I’ve had in the past getting VB scripts written)?
Last, I guess a LOT of people are looking at this, when taken with MS withdrawing development of Virtual PC, as MS looking to withdraw (slowly) from the Mac world. It’s unfortunate that those two things had to be announced relatively simultaneously, as it doesn’t give the community the best “feel” for MS’s Mac development efforts.
So, to summarize – loss of VB is an issue if it’s the loss of scriptability entirely, but otherewise, is not a huge loss if we can get VBA support perhaps later. PC to Mac conversions of documents will now be problematic, but it could be worse, and based upon the tech reasons you’ve desribed above (cost of development has to be less than revenue earned, or it’s not worth the time/effort), I can understand the decision.

Personally, I’m less concerned about the loss of cross platform scripting than I am about the loss of _functionality_. The current Applescript interfaces will have to significantly change to make porting of VBA code possibly. For example, VBA can add toolbars, buttons, menus, etc to the application and wire them to trigger a Macro. There’s no equivalent way to do that in Applescript. Then there’s events such as Excel’s SheetActivate. In other words, applescript allows outside processes to perform actions on the office application/document, but there’s no way to initiate an action from inside of the application (I guess you could add a script menu but that’s an unacceptably poor substitute). Plus, there are some things which are simply not available to applescript such as tags on shapes in PowerPoint. To stand a chance, whatever scripting Office offers will have to at least match the feature set of VBA.

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.

Great explanation and it’s fun to read some of what’s happening behind the scene here. One possible solution that you didn’t mention and that’s much more viable nowadays than it was in 1996, is to rewrite/rephrase the assembly bits in C++. If the VBA runtime would be in C++, it’s the same on PPC and Intel. It might be a little slower (not even much), but I guess that most users don’t expect scripts to run very fast, and computers are much faster now. It’s definitely the route I would take (and I’ve got a fair bit of assembly code to maintain myself that I wish I’d written in a higher level language a couple of years ago).

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

I believe that you might not see the point. People are wondering what “you” guys at Microsoft are doing anyways, except from reinventing the doc file format
(man, your engineers must be rookies, there wasn’t an Office version without a new doc file format!).
From a developer’s point of view: OK, your old code is not portable, is clumsy, haunted, whatever. VBE is the only editor that works, VBA converts to some assembly code – sorry, but it sounds like that code sucks. It worked for many years, but now it’s a dead end. So, you had to decide between porting and dumping. Wait! DEVELOPER’S POINT OF VIEW, remember? I don’t know much about VB, but how hard can it be to write a (modern) interpreter from scratch?
I mean, people PAY you, and it’s far more than a shareware fee!
Please Microsoft, please stop shooting your feet!
I’m not the “Microsoft bashing Linux freak”, I like your research labs,
Microsoft press publishes great books and I’m sure there are a lot of smart people there, but really, it’s like the new philosophy is to crash projects.

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 used Excel macros and subsequently VB to write routines to maintain test results for my lab for years. We have bought the latest versions of Office since I don’t know when and have been loyal Microsoft Office customers.
What this decision to drop VB will do is prevent our company from upgrading to the next version of Office in order to maintain our ability to enter and analyze data. I fear that this scenario will occur in a large segment of the Mac community. Resulting in less revenue for Microsoft from “Office for the Mac” sales and Microsoft finally dropping all support for Mac OS using sales as a reason.
The only thing that I’ve read that may counter my suspicions that Microrsoft is not moving toward abandoning Mac OS is that Microsoft is also deprecating VBA for Windows and that office for x86-64 is dropping VBA support. I don’t know if this is true or not, but all in all I’m quite frustrated with this decision.

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…

Having worked in the MacBU and being involved in the decision to end development of Mac IE, I can understand the frustration the Mac Office team must be feeling when they see people so confused and angry with this decision. What people must remember is that every company, even the biggest/richest, is a business and must make intelligent decisions about opportunity cost.
It’s clear that some number of customers will not upgrade to Mac Office 12 because of the lack of VB support. Most likely, this number will be far outweighed by the number of people who do choose to upgrade to or buy Office 12 because of the new features and improved reliability and performance that was made possible by refocusing engineering resources away from VBA.

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)

Thanks a million for this very long and detailed post presenting to us the reasons why VB will be axed from Office. I understand your points and coming up to this decision must have been really tough.

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.

[…] First off, the Microsoft MacBU people have had a couple of amazingly good posts this week about some of what makes running software teams so hard. Schweib has an amazing post about MacBU’s decision to drop support for VB in the next release of MacOffice. He gets into some architectural details of the VB implementation and of the necessary changes to support Intel, Xcode, and 64-bit. […]

“Many people have viewed this announcement by MacBU as a sign that we are out to screw the Mac community, or that we’re just looking for an exit strategy. We’re not. Most empatically, we’re not.”
Just because you abandoned IE, Windows Media, VBA, and VPC, doesn’t mean you don’t want Mac users to feel like they’re getting screwed over, after all, who uses those in the real world?
On the bright side, with VPC and VBA gone the way of the Dough-Dough, maybe now you can put all your resources into MSN messenger 6.1, where you can finally get that Animated “Sticking out your tongue” emoticon mac users have so desperately been begging for, instead of that Video thing programs like AMSN have.
You WANT us to believe that you aren’t screwing us over, you aren’t looking for a way out, but with each product you abandon for Mac, it’s getting harder and harder to believe it.

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 realise that this was a very difficult decision to make, but I really think that you guys are taking the wrong path. As you suggest, the majority of Mac users do not use VBA macros, but for those that do – it is an absolute deal breaker.
I think it is important to offer some sort of VBA compatibility, even if it is slow, even if it is a separate download etc.
Is it possible to pull the VBA stuff into a separate process so that still run through Rosetta? I suppose there is no point asking to bind the Win Office VBA stuff with winelib 🙂
What about outsourcing the effort to RealBasic – they appear to have the code to cope with parsing VB style code – maybe they could make something that interpreted the VBA code and then drove Office using AppleScript (or even better, do you expose COM interfaces on Mac too?)

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.

If you can integrate Applescript in a way that makes it truly useful, then you will have done Mac users a service. Thanks for the clear explanation. Those who only wish to bash Microsoft, and specifically the MacBU, then get over it, please.
Now, about Exchange compatiblity in Entourage. Now that you have more developers avalable for other jobs, please, make Entourage work more like Outlook! At least make it easier to set up, and more compatible with Exhcange Server.

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.

Wonder how many features Apple or Adobe have had to remove from their products lately as a result of going to Universal Binaries.
I’m gonna guess the number is pretty low, if not zero- and not something like VBA. You might reflect on that and whether or not that has implications for the MacBU going forward. The list from the MacBU is pretty long the last few years: MacIE, OE, VPC, VBA. Far more so than for any company producing Mac software. And it says something that the last two big events in the Apple world (MWSF 2006 and WWDC 2006) have had Microsoft doing a “one step forward, one step bacK” dance (“Yay! We love the Mac! Oh, and we’re cancelling stuff!”).
Yes, I know, you’re not doing this out of malice or because Emperor Bill wants to crush the Rebel Apple Alliance and you’re simply his minions. I’m just saying features delight customers. Cool stuff delights customers. Cancellations and explanations why you have to kill things? Not so much.
Yes, I know, Software development is hard (I’ve been on a team where we did something very similar to what you did to VBA). Sometimes choices suck. I think, though, you need to realize that the road to hell is not just paved with good intentions, but with fragile corss-platform software, and Apple’s not going to be sitting around with iWork- and they don’t need 3 years to turn the crank before they RTM, and I’m guess they aren’t going to be screwing groups of their users by removing functionality anytime soon, even if you have good reasons to do it. I worry that the optimism of Mr. Grewal’s a bit misplaced in such an environment.

[…] Schwieb: Saying goodbye to Visual Basic Schwieb » Blog Archive » Saying goodbye to Visual Basic Well, its been less than two days since the MacBU announced that Visual Basic is being removed from the next version of Mac Office. The news has created quite a firestorm on many Mac forums (I’ve been scanning MacNN, Ars Technica, and a few others) and I received some very strongly expressed opinions about it in comments on yesterday’s post. I’d like to take some time to express my own views and experiences on the removal of Mac VB. […]

“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…

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.
As it stands, we’ve got OSA components for JavaScript, Python, Ruby, PHP, Perl, TCL, and sh. VBA should be very easy to match up considering that list. The OSA component shouldn’t be terribly difficult to write – you could contract with someone like the Late Night guys since they did the Javascript one. Yeah, you need to hunk out of opcode, but that part doesn’t sound like one of your problem areas.
In addition, all of your external API work would still be reachable by Applescript and the others mentioned above as well as Automator, so you would continue to make it more Mac-like.
It’s not like VBA needs to be fast – it just needs to work.

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.

Why would anyone consider ending VPC an issue. With the move to Intel Macs, the product is obsolete. I wouldn’t choose to develop a new version either. So far as dropping IE and OE, those were both free programs–when referencing other Mac software companies and how little they’ve cancelled, consider whether they were giving the stuff away free. There are tons of alternate mail clients, so what again would be a business case to continue to offer OE?
Cancelling IE and WMP is more distressing, since there are still so many sites that only work well with IE or WMP.
But as to removal of VB from Office, yep it sucks if your company is dependent on VB. So stay with the current version.
The reasons for the decision are fairly clearly presented. A lot of the complaints–not all, but most–demonstrate a complete lack of understanding of what it would require to rewrite VBA in X-Code in such a way that it would also retain compatbility with VBA in Windows.

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.

First of all, thanks for a valuable post.
Secondly, I would like to add even more arguments for dropping VBA.
I am running a whole line of business in the software company, so I do understand reasons why VBA should be dropped. The product should be balanced and should be focused on the user and most common usage scenarios, not the abstract notion of “must have features”.
I am using Mac as my office machine (and I am the only one in the company), and I should accept my current habbit is to run Office on Windows using Parallels every time I am going to dig into a really complex Excel stuff. That is because even current Office for Mac has problems such us lack of support for OLAP cubes. Also I am never sure that a macro from Windows Office would run as well under Mac (and in quite many cases it really would not).
So no big issue for me. For corporate usage of Macs in Windows-based corporate environment Parallels or Boot Camp or a separate windows terminal server access by RDC is a must anyway. I have found many cases when Word for Mac could hardly be used with documents created in Office 2003 (font compatibility problems leading to layout being crapped, comments not shown properly, document reported as being too complex to edit, etc). Not saying about DFS not being supported in current Mac OS X, and a bunch of in-house corporate software either having Windows client only or tested under MS IE only. If so, then there is no need to complain on this specific topic when it comes to corporate use.
For non-coprorate use macros are more a problem than a possibility, as they create many issues. For occational Mac users AppleScript is a much better alternative, as it integrates well with other software and is obviousely much widely used by Mac community. Also one should consider different kinds of security threats ported along with VBA from Windows platform to Macs. AppleScript engine could be tightly integrated into the product, so when implemented properly we will see more benefits than losses for occational users.
So this is 100% reasonable decision, and I fully support it.
Anyone who may have Xls files containing macros, if you would like to help Novell to improve support in, 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.

Just to add my 2 cents:
“Intended for Intel Mac OS X machines, CrossOver Mac will allow Mac users to run their favorite Windows applications seamlessly on their Mac, without the need for a Windows OS license of any kind.”
At least people with Intel Mac will be able to run the Window version of MS Office…

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?

VB we’ll not be longer required for two main reason. Microsoft we’ll drop it on the next Office for windows too. And chances are great that Micrsoft can user c. net on Xcode if they programm a plugin. Microsoft BU seems to understand that Apples developer tools work well since 2.0.
The second reason are Virus. VB was often part of a security risk. This can be avoided whit tools like F-Script, Applescript or some Java tools.

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.

[…] Reader nhmacusr has provided a link to a blog which is apparently written by a member of the Microsoft Mac Business Unit who has posted an entry explaining why VB scripting will not be included in the next version of Office for Mac. It turns out there is a technical reason I wasn’t aware of. The Cliff’s Notes version is, writing VB for Mac Intel and Mac PowerPC would require a tremendous amount of work, for technical reasons, and would delay the Office product by two years, and in the end, the functionality would be equivalent to what Office provides today, which would be out of step with Windows Office. The Mac BU would rather work on making Office more Mac-like and implementing requested features than busting their hump for two years, while everyone impatiently waits, to provide something that is already outdated. […]

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.

eponymous – While it might not take Apple three years to turn the crank on iWork, each crank turn isn’t doing much in the way of new features. We’d never hear the end of it if we had a scant handful of new features on each rev.

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.

Thanks for the informative posting about the inner workings of the Mac BU.
I can understand that reworking the VBA to emit Intel code that confroms to Mac binary interfaces must be a nightmare. But it sounds like the VBA compiler is a kludge. The description of “bit twiddling” makes it seem more like a hack than a carefully designed compiler.
With the blazing speed of today’s processors, why not just write a high-level interpreter? You could start with a straight bytecode interpreter and later (in a subsequent iteration or release) add a JIT compiler.
A bytecode interpreter would give you the VB compatibility without the hassle of emiting Intel machine code. Yes, it would be slower than native code, but I’m sure your users would gladly trade a speed penalty for not being able to run VB at all.
Another possibility came to mind (I think a previous poster mentioned this): how about hooking the existing VBA into Rosetta? While the rest of Office ran Intel native code, VB runs under emulation. Is this possible?

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

I know of no corporate site that fails to extensively use VBA in Excel, and nearly all use it in Word. This will single-handedly kill cross-platform sales in the enterprise.
It’s imperative to solve this problem in a cross-platform way. The current one solution does not, and I hope there’s time to fix it.
You make a reasonable argument for killing VBA (and I’m a developer so I understand how hard the porting is), but understand that this decision is in fact breaking compatibility–the key reason for Office to exist on the Mac. No VBA means a shrinking market, and ultimately, the end of MacBU.
It doesn’t seem like you see it that way, but keep in mind that VBA is used for the banal, everyday worksheets passed around companies. I have to run a separate copy of PC Office now to fill those out–so why buy the Mac version in the first place? While the roundtripping of files still works, key functionality in those files do not. To say that Office is ‘cross-platform compatible’ is not accurate anymore–it’s not.

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!

It seems to me that if you support the object model and it’s close enough to what’s needed to accomplish the same tasks as VB, then all you need t do is write an Open Scripting architecture compliant compiler for the VB syntax. If done correctly people could chose between VB and AppleScript and you wouldn’t necessarily alienate all the existing VB users.

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.

There may be valid technical reasons (OK, i get it, it will be difficult…) but efftively this decision does the following:
1. Removes cross platform compatability between the apps from WinOSX
2. Removes funtionality I have today in my current version of Office (actually still running on Office v.X)
3. Hamstrings the possibility to use a Mac in many professional workplaces
4. Give many users a reason not to buy the next version of Mac Office *or* drive them to buy a Windows XP/Vista license and the PC version of Office (or Excel) – will they get a discount on the PC version of Excel for my trouble
As a trade off to this we might get a ‘better user experience/more mac-like code’ hardly seems worth it.
Will it deliver less buggy code?
I’d like to make another point:
Since when has anyone in the Mac BU even cared that the Office version has lagged on the OSX platform before? We’re used to being two or three years behind. :-/

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.

What a piece of crap. Blame it on the old code.
How about you hire QUALITY engineers who CAN get the job done? Clearly you guys can’t.
Regardless, you’re just hiding behind the true reason: MS *DOES* want to stick it to Apple. This effectively screws enterprise customers from buying Macs precisely at a time when Macs are making more inroads. Nice job, bubba.
At least you’re not laughing all the way to the bank with your stock price in the tank.

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

“One final problem is that all of this custom assembly is currently PPC 32-bit, and even the corresponding Windows assembly is Intel 32-bit. If we ever want to make a 64-bit native version of Office, any work we might do to solve all of the above problems would have to be done all over again.”
If I understand this correctly, Windows users shouldn’t hold their breath if they’re expecting a 64-bit version of Office that’s compatible with the 32-bit version, assuming Microsoft even decides to create a 64-bit Windows version of Office.
That VB for OS X was basically based on Office 97 says a lot to me about how important this software has been to Microsoft.

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.

I’ve recently had some major VB Excel headaches that cannot be resolved. An excel file created in a Spanish Office v.X Excel would not run without runtime errors on an English Office 2004 install.
All the work that went into that file (many months) is now all but useless. The same file works on current PC Office installs.
The person who created the file is not happy. This person works in education and has reported that more and more training courses for teachers are offering Linux training. We are talking about a region with 7,000,000 inhabitants. Other regions have already implemented Linux solutions and are looking to phase out Microsoft Office completely.
Microsoft needs to understand that users want/need seamless compatibility between platforms. This latest decision only helps to swing the balance in favour of open standards and software solutions that support them.

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.

Problem with Applescript substituting for VBA in future revs is that each modification to a SS originating in Windows (i.e in the Corporate World in general) would represent a new or partially new porting “opportunity”: VBA–>AS
For example: Travel dept (which uses Windows, of course) puts out a new version of the Travel Expense Reporting SS, with some changed and some additional macros. I can’t use that SS in Mac OS X until I port the changed and new macros to AS, assuming the port is even possible.
Now consider all the other parts of a big, Windows-oriented company that might generate macro-containing SS: personnel (e.g. retirement-planning SS); purchasing; sales; planning; accounting; etc, etc, etc.
That’s not even counting externally-sourced SS with macros, from suppliers, contractors, govt, etc.
My brain hurts. I want to poke my eyes out with a Sandisk Cruzer.
Only a fanatical micro-population of Mac users would even consider getting on such a treadmill, much less staying with it for more than the first 2-3 ports.
I would start using Office for Windows in such a circumstance.
Looks to me like an exit strategy for MS. “Now look at what you Mac users made me do!”

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!

So in a nutshell: While you have been adding in such notable features as a animated paper clips, ‘notepad view’, and working very hard on making sure Entourage uses a proprietary database (and a single, huge (and hugely corruptible) database, you have neglected VBA code because it is messy. Then rather than rolling up your sleeves and fixing it you just throw in the towel and cry about what a ‘difficult decision’ this is. Then someone got the bright idea to just use Applescript instead. Great, so not only well VBA scripts written on the Win version of office not work on Macs (even scripts that I wrote on that very same Mac), but now scripts written on the Mac will not be compatible with the Win version. Hello? Are you really sure this is the best decision? Lets try again, shall we? Why don’t you just lie, and say that VB is being dropped from ALL Office products, to be replaced by xxx. Since xxx is not complete, it will not be included in the next version of Mac Office 2007, but it will be added as an interim update prior to Mac Office 2010. At least try to have the appearance that you are doing something about it, not this ‘its too hard, so we are just dropping it. We don’t know what we well do now, maybe Applescript? I dunno”. This is really pathestic, actually, and if I were working at the MacBU I’d be damn embarrased right now. Are you really surprised you have so many problems attracting good people? I’m not.

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!

Well – Thank you! What wonderful new that is!
As a long time Mac consultant, I’ve set a policy of keeping my clients as far away from MS products as possible, at least in regard to mission-critical implementations. There are plenty of solid, stable, secure, and cheaper alternatives around.
Microsoft has just validated our position in the eyes of a whole bunch of corporate clients, and we should soon be getting apologies – and “so what do we do now?” letters – from the few who decided to go against our advice and invested on VB. Those clients who trusted you, instead of us.
Not to mention the billable hours we’ll get resolving that nest of vipers. I think I’ll take my wife on a cruise this winter.
So, thanks again, and keep on the good work.
In view of this, Y2K, Blaster, and a few other events, you may want to consider a new motto:
Microsoft: Key partner of tech support companies, worldwide.

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.

I’ll just say “me three!” to the request for more information, regarding the idea to graft on VBA via Rosetta, leaving the rest in native Intel.
Excellent post. Excellent blog. You’re motivating me to do the same for my company.

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

Very grim news, not that it has been fun working with a Mac Excel VBA that is ages behind the Windows version anyway.
How do the Microsoft lawyers feel about defending the firm against claims of monopolistic practice now? This decision should not be a business unit decision but a corporate one.

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.

On Ars I did suggest that one option may be bundling 2004 as a ‘fallback’ mode into the next version, for people that really need to still run VBA. Not even a clever hack, just ‘This document contains VBA macros that only work on Office 2004. Open in Office 2004?’.
Of course this would only work for as long as Apple support Rosetta, which I’m sure will only be as long as Classic support has lasted.

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.

Thanks for the technical insight but for all of that information and backroom decision making, it seems those in charge of the Mac BU just signed their own eventual death sentence as opposed to letting some higher up Microsoft executive doing that dirty work (yeah, Allchin retired but it was well known how he was one executive out of who knows how many who didn’t like the Mac BU) and letting the Mac BU knife themselves. There’s a segment of corporate, educational, and government customers who have certain requirements which this product isn’t going to meet so why would they invest in a product which doesn’t meet that need? And aren’t such volume site licenses lucrative when compared to sales from individual customers?
Some Windows heavy organizations only tolerated the use of Mac’s because of Mac Office’ compatibility with Word and Excel documents. The complete loss of VB (even if it was still not up to what is available in Windows Office; at least there was some compatibility) is going to be a deal breaker and just the good enough reason needed to say no to Mac’s. For those who don’t end up being affected (they can still use Mac’s) but still require at least some scripting compatibilty with predominantly Windows created documents, there is little incentive to upgrade to a new version when it does not fill a certain requirement. Likewise, if a competitor comes out with something which does fill that need, customers (especially corporate, educational, government ones) are going to migrate there. The most likely scenario however is many will just dispense with the headache and require the use of Office for Windows.
End result in all of these scenarios is less sales of Office for Mac which bottomline affects the Mac BU since it is about the only revenue generating product keeping you folks relevant now that most every other meaningful product in your division has been chopped off. I’d be surprised if the Mac BU remained intact after this version of Office is out and that 5 year agreement time period has ended. Good job!

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.

I don’t care how hard it is to code. With no VB, we’ll be saying ‘bye, bye’ to Mac BU. We will not be upgrading to the next version of Office for Mac. Despite your claims to the contrary, I suspect this is what MS ultimately wants, now that Macs can run Windows. Why bother when you can double your pleasure by sticking Mac users with two purchases, Windows and Office, instead of just one?
Hello OpenOffice! Help!

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.

The MacBU might as well close up shop. Excel & Word without cross-platform compatibility is close to worthless. 90% of the document templates we use in our multinational business use VBA sucessfully on Windows and Mac Office 2004.
I would not be surprised if like me, most people would find moving to Mac Office 12 would be a downgrade without VBA, and hence paying for the new version would be out of the question.
Is the MacBU just wasting it’s time working on a new version that few people will want ? ?

Agreed. Fire the MacBU. You people obviously wrote crappy things to begin wtih, can’t even keep promises from senior level management, and take way, way, way too long to get anything done. Your entire business model has been based on the fact there was no competition. Well guess what, that is no longer true.You might as well transition over to helping the Vista team get things done before 2020.

[…] For people who understand English, Erik Schwiebert posted a very detailed post explaining why the MacBU decided to drop VB support from Office 12: “Saying goodbye to Visual Basic” For people who are not comfortable in English (or not enough to read the entiure post) and who understand French, I tried to summarize the situation in French in the lower section of this post. I definitively don’t need to add anything since the post says it all. The least I can say is that I definitively am worried for all third party solutions that relied on VB support, but the future will tell how that will impact Office 12 adoption. (on a personal note: I sure hope the Thomson Research people are already working on finding another approach for their EndNote add-in for Word 12 :- ) […]

As a developer I can understand the dilemma that the MacBU faces with moving Office on Mac to support Intel. As a developer I can understand having to make hard decisions that may aggravate some of the installed user base. As a developer I see the reasons given illustrate the horrid coding practices at MS in general.
As a customer I see this as another indication of Microsoft’s continued superficial support for the Mac. The loss of Virtual PC for the Mac Intel platform is not a big deal, and there’s no reasons for MS to continue migrate it given far better solutions already available. The loss of IE was for the best given the complete inability for MS to support basic standards in modern web browsers.
The loss of VBA in Mac Office isn’t a huge loss in and of itself, however, the fact is that now there will be a roadblock to effective sharing of documents between Mac and Windows users. Offices that make extensive use of VBA and consist of a mix of platforms will now have to make a decision as to which platform to focus on. The choice is going to be simple for those that are heavily invested in VBA usage. It seems to me that MS is far from ignorant of that sort of scenario.
I don’t believe blaming the MacBU for this situation is fair. They have done well with what they have. Sadly, it seems the very existence of the MacBU is merely a gesture to show that MS supports competing platforms in some meaningful manner.

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.

I use Word for writing school reports.
This whole page is so surreal for me, because I can’t believe VB support on Mac is such an Issue to so many people.
Nevertheless, the post was interesting, and it seems from the comments that its all too easy for people to make unreasonable demands, but it’s nice that others appreciate the technical complexity of what’s involved… 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.
Looking forward to the next version of Mac Office, especially if it boasts a more Mac-like UI/experience.

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.

Thanks for the detailed explanation from your end of things about the issues involved.
In the end though, the nagging sense remains-that Microsoft is willing to support the Mac only to the point where they can a) make some money (which is totally justifiable of course), but b) to always make using MS applications on the Mac a “sure, but..” experience.
i.e. “sure you can use WMP on the Mac..but..” “Sure you can use IE, but…” and now, “sure you can use Office on the Mac..but..”

Totoro! 歩こう、歩こう。。。私は元気!
Yeah, there are some perception issues we might want to address. Thanks for the feedback.

Paul Topping,
Glad to see Design Science on here. Yes, EqnEditor (and Mathtype) along with EndNote are some big issues we need to address. Currently (even in Office 2004) there’s a pretty darn close to 1:1 mapping of VB and AppleScript to do what you need. There’s probably a few things missing so we’ll have to chat to see exactly what code you use. I’m sure we’ll be talking to you or other folks at your company extensively in the next few weeks.
In the meantime, I plan to post some sample VB->AppleScript code snippets to show a little bit how things can be done. Perhaps next week…

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!

I don’t know why you’d want to bother working on Mac Office at all with the amount of bile and abuse your subjected to in these comments.

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…

[…] In other news, Microsoft has decided to drop VB from the Mac version of Office. They’re open to suggestions. I would have thought the only point of Office on the Mac is to be 100% compatible with Office on the PC. It’s odd that they’re not just migrating to x86 for future versions of Office: Compile the Windows VBA engine with MASM, munge the binary to link into gcc. Yes the ABI isn’t compatible, but that only affects the input/output edges of the engine. I’m surprised that’s a concern to a company that invented thunking… […]

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.

So, this is a result of years of incompetence: bad VB language design, bad coding practices? I guess these are also reasons why MS has such a hard time shipping.
But maybe this is just bullshit – writing a parser and interpreter/compiler is not really rocket science, even for a shitty language like VB.

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?

Thanks for your post – I understand and believe your motives for dropping VBA. I still however feel that you underestimate the need for cross platform scripting in Office.
Mac users don’t use Office because it’s the most Mac-like solution, they use it because it’s compatible with Windows Office. For example, the text engine in Word is completely custom to ensure compatibility with Windows Office.
Providing applescript access to the VBA object model is nice, but it doesn’t in any way alleviate the need for cross platform scripting. Office is above all thing, a cross platform standard and the minute you guys move away from this you are failing in (what should be) your primary goal for the product.

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.

Thanks for the info/explanation. I find it reasonable and while I will miss having macros in Office, I’ll bite the bullet, learn AppleScript, and go on. I don’t share macros with Win users, so this isn’t (currently) an issue for me.
I do find much of the explanation surprising, though — things like ‘the source code doesn’t exist.’ It really makes MS look more like a skunkworks and less like a professional software developer.
I can’t imagine any of the suggestions I’ve seen so far working, at least not for the next version of Office, but I like the idea of including a copy of Win Office. Maybe a coupon the Mac user could mail in for a Win Office CD set if the need VBA support? Then they could run it under Crossover or Parallels. Not elegant, but acceptable to most.
I still remember a few years ago when the “it looks like you’re managing a list” feature started popping up. MS research showed that a large percentage of their users on the Mac side were using Excel like a database, so they added the feature. Why not? Windows users use Access instead of a real database, just because it’s there — why not Excel? Anyway, the point is that the audiences are very different. I’d guess a pretty tiny percentage of Mac Office users have ever touched the macro feature.
And on the bright side — killing VBA means no more Word macro viruses!

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.

Thanks for the post and for your explanations. However I am very disappointed to hear of the demise of VBA for Mac. This will considerably affect Mac users in corporate environments. File and function compatibility is VERY important for corporate users.
Some examples of use: I have done a significant amount of VBA programming in Excel and PowerPoint over the years – most of this on the Mac to be used on Windows and Mac. This VBA stuff is used in various places in our company from timesheets (press buttons/choose from menu items to format, check, update database and prompt user), quality control of scientific data (automated plots including wind vector fields using arrows), specific complex functions like calculations of vapour pressures, potential temperature, etc. I don’t see applescript doing this (quite apart from the compatibility issues with Windows!!). VBA in Powerpoint enabled the merging and import of hundreds of matching gif file pairs into an endlessly repeating Powerpoint show for display.
Some suggestions:
– Run the current VBA code under Rosetta with the rest native until the VBA code is updated.
– Contract out the VBA code update.
– Talk with (contract them) the “REALbasic” people to enhance/merge the “REALbasic 2006” code and merge within VBA. Their website states that “REALbasic is highly compatible with Visual Basic, so Visual Basic developers are productive very quickly with REALbasic”.
So please, please reconsider your decision – for corporate users in particular compatibility is important!!!

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.

There’s discussion of the implications of this move over at the Mellel forum. This is what I posted:
I think the lack of VBA support will force most large organisations now using Office on both Macs and PCs to move entirely to Windows Office, because they typically rely heavily on VBA macros. No PC macros will work in the Mac version and no Mac macros will work in the PC version. Mac users may be allowed to run Windows Office on new Intel Macs, or they may be moved over to PCs, depending on the organisation.
What about home, academic and small business users? They will be aware of the trend for Mac Office to become even less compatible with Windows Office than it is now. Anyone who needs full compatibility will have to buy Windows Office, as you do now if you need proper support for multiple languages in Unicode. The difference from now is that by next year a lot of people will have Macs capable of running Windows Office at native speeds. To some extent, then, the next version of Mac Office will be just another Mac word processor, competing with Mellel etc. on features and ease of use, rather than being an automatic choice as it is for many people now.
I don’t use any VBA macros in Office (except maybe the Bookends toolbar), but I doubt I’ll bother to ‘upgrade’ to the next Mac Office while I’m still using a PowerBook. And when I — eventually — get some kind of MacBook, I’ll probably get Windows Office so I can be sure that files I am sent look exactly how they should. I don’t know how typical I am, but I suspect a lot of home users will not upgrade and others will move to Windows Office on Intel Macs. Together with the demise of Mac Office at most businesses, use of Mac Office may seriously diminish over the next few years.
All of this puts the next but one version of Mac Office (Office 2009?) into serious question, I think.

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.

The only reason a lot of Mac users still use Microsoft Office is to ensure compatibility with a lot of people who run the suite on Windows.
Compatibility by all means includes VB macros. We need to open those files, use them as they are, and save them. I’ve personally written Excel macros (on Windows) that are absolutely essential for using the document in question. Without the macros, there’s no point in even opening the document. Rewriting scripts in AppleScript is absolutely, positively out of the question.
Microsoft needs to add the functionality later if it is to maintain the Mac user base. Otherwise, Mac Office will very simply not be compatible with Win Office. There’s no other way of putting it.
Thanks for the explanation. However, it’s Microsoft that we’re talking about. Compaining about the lack of resources will do little to ease the discontent. I understand that the Mac BU is probably not to blame for this, but it would be difficult not to transfer the blame to greater Microsoft.

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

[…] Et bien à partir d’Office 2007 Visual Basic ne sera plus de la fête sur le Mac coupant d’entrée la compatibilité des applicatifs développés autour de Word ou Excel. Les macros seront préservées, mais inutilisables. […]

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.

Oh boo-hoo… That’s a whole lotta words to roughly state what George W Bush did in defending his own administration’s abysmal failures. In that case, three words summed it up:
“It’s hard work!”
What seems to be increasingly hard for Microsoft is giving customers an actual reason to consider upgrading. The ongoing trend of breaking existing applications in order to generate churn is apparently the only viable strategy left, given the state of “good enough” was achieved to most folk’s satisfaction some years back.
The one thing OpenOffice offers, that I and millions of others are convinced Microsoft can never offer again, is Trust. Y’all have blown it all to shreds, and continue to show absolutely zero understanding of that simple fact. The only justifications offered anymore are cost/benefit, but in every case those are stated from your perspective only. It’s long past time to realign the sights, and once again consider the costs/benefits of and to your customers!

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.

Correction: I said “The short summary is this: many only use Word because it works with Bookends” I meant, of course, EndNote.

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.

You appear to be locking yourself to Apple tools, when “Intel is your friend” in this matter…. compiler and cross plat work…

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

I have invested literally hundreds of hours in thousands of lines of VBA code that perform custom text-parsing operations on MS Word documents. By pulling the rug out from under all this work, and destroying the value that it brings to my clients, when there are reasonable alternatives (as suggested in other posts), Microsoft is demonstrating its contempt for its own customers. Word 2004 is already extemely slow to update the display after editing operations (on my 2.1GHz G5), and VBA has been the only reason to put up with that. Mac users who don’t need VBA already have other word-processiong alternatives; it’s the power users who are willing to shell out for Office, and these are precisely the people you will alienate most by following through on this decision…

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

[…] Would you believe that Visual Basic for Applications runs in an environment that features dynamic code generation and behind-the-scenes vtable munging of C++ objects? Until I read this article, I wouldn’t have either. To be fair, what reasonable person would assume that a much-maligned macro language would be a playground for so much fun technology? Note that the dynamic compilation is strictly on PPC — the Windows version of the interpreter/VM is “tens of thousands of lines of IA-32 assembly that directly implements all of the opcodes.” Sounds like a threaded interpreter to me (as well as a maintenance nightmare). […]

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?

This is great news. The death of Mac Office.
Basically what this means is that all the employees at the MBU at Microsoft have just made sure they won’t have jobs in 2 years.
Microsoft made the Zune, can’t they get VB to work? Oh, forgot the Zune is stupid as so goes the MBU. The Zune and MBU will go down together. Whoever was in those planning meetings in the MBU, you should all just look at yourselves and think WTF did we just do, we killed mac office and our own jobs. Just such a bad decision.

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.

Yes, that big unstable goon Steve Balmer, said enough is enough, Apple is making me look more stupid every day. End it some how, someone change the subject. Yea, no more Mac Office, that will get everyone afraid again of Apple going out of business.
Everyone… it’s Steve Blamer, the goon that can’t make one good product. It’s too bad the only good software unit at Microsoft is now being hog tied by the Balmer.

Ack! I just saw the news on MacCentral.
VBA, for all its quirks and bugs, is one helluva tool.
After you’ve built up a library of dozens and dozens of useful ‘snippets’ and assigned them to menus and buttons, you can (I swear) improve your productivity in Excel by an order of magnitude. I can literaly do stuff in Excel in 10 minutes that would take an average Excel user a day or two.
And I have used Excel’s VBA to write thousands of lines of code for our staff. I cannot tell you how many times one of our finance or admin people has groaned and said, “Oh crap. Massaging this Excel page to get what the CFO wants will take me all afternoon.” I show them a few tricks, put a few bits into VBA, and presto, after 15 minutes we have what they need and something they can use in the future, to boot.
The folks above are right. If VBA isn’t available for the Mac, I’ll certainly stop using Office for the Mac.
More importantly, though, I’ll stop helping the PC Office users at work. I’m a busy guy. I do a lot of this VBA work at night after the wife and kids have gone to bed. Like so many of you, I use a Mac at home, but am forced to use a PC at work.
And once I’ve stopped helping the Excel PC users at work, their productivity will drop dramatically.
And, once that happens, I’ll get a call from our IT guys (like I do every couple of years) and they’ll say, “Hey. What just happened?”
And I’ll say, “Microsoft screwed us again.”
And they’ll say, “Yup. Just like last time.”
And then we’ll all go out for a beer and laugh at how we fell for it yet again.
Sometimes it’s really true that for want of a nail a kingdom is lost.
VBA is that nail.

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?

“A couple of months ago I wrote that I hoped my blog would help people trust the MacBU a little more”
If anything a decision like this makes me trust MS even less. MS seems to be out to screw mac users every chance they get, axeing Windows Media Player, IE, gutting features out of Office to make it less compatible with the Windows version.

[…] Deixando os pormenores técnicos por detrás desta decisão (que podem ser consultados aqui) eu até acredito que seria tecnicamente difícil e moroso implementar as macros VBA para Intel/Mac. No entanto, sendo a Microsoft a empresa que é, detendo os recursos que detém, só posso concluir que isto é uma forma de levar a que muita gente volte outra vez para o Windows para poderem abrir/manipular documentos Office com macros em VBA. A dificuldade do problema é usado como escudo para ver se cola. “Oh coitadinhos, um gajo paga 400€ por cópia do Office, nós não queremos que eles tenham muitos problemas!”. […]

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.

And one of the posters up above made a really good point:
Apple has made Mac Office 2004 (including full VBA functionality) run on Intel via Rosetta. Why can’t that be done in the next version of Office? Keep the VBA components compiled for the PPC architecture and let Rosetta emulate them while the rest of Office runs natively.
Certainly that would involve some coding and creativity, but it has to be possible.

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.

I appreciate the explanation behind terminating VBA. It must have been a rough one. For those of us who depend on this functionality, it will push us to other options.
While VBA support in Office 2004 helps with a semi-seamless transition between Mac / Win Office, I’m finding myself using my VM more and more in Office 2003 on XP via my Mac. The bottom line is that for corporate applications utilizing VBA, I’ll have to live in that VM. However, I will continue to use and support Office for Mac as I find Entourage to be a DRAMATIC step above Outlook. Kudos for the thought and design of that product. I hope that the next version continues to be leaps and bounds ahead of the Win / Outlook platform.

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.

Can a unified file be created?
By that I mean, first, can a single word or excel file hold a complete set of both mac and pc macros, will both platforms round-trip all macros they know nothing about, and can each platform add similar macros to the file without interfering with the other platform?
Such an ability would not make life easy or reasonable for the average user, but it would allow those few situations where a major piece of functionality is built into important enterprise office docuements to continue to function, with each customer being able to decide if the extra version (mac) is worth writting and maintaining based on their own dependence on the mac platform. Most will make the decision not to do such a thing, since in the long run it can only lead to incompatible behavior anyway, but many mac centric companies would need just such an ability.
It seems Mac Office primarily exists in the marketplace due to compatibility. Heck if you read your own history you will know that excel only ousted Lotus by being completely format compatible. If you don’t have sufficient compatibility then you will be competing on the mac platform on mac-native features and look-and-feel. Interestingly you get that fairly well most the time, and in fact have a better user experience than the windows version of office, but there have been many products Mac office has defeated in the past solely due to your compatibility, and such conpetition will occur again, inevitably.

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.

Say goodbye to visual basic and hello to Visual C++ Express.
One of the disadvantages of Visual C++ Express 2005 is the fact that it does not come bundled with 64 bit compiler support. Now if you have a 64 bit server or workstation you’ll likely want to compile your own 64 bit binaries. I figured out a way to do this using the Platform SDK. Check it out.
One of the main advantages of 64 bit processors is their ability to allocate more than 2GB of memory for a process, and its free to build 64 binaries for windows now.

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

All explanations and whining about challenges aside, it is not acceptable to eliminate a technology in Mac:Office that is still supported and in wide use in a previous version of Mac:Office and in previous, current, and future versions Windows Office. All your dissembling does not make sense any more than the thin excuses as to why you could not start OOXML converters until Window Office 2007 was final. Obviously the Windows team could work with non-final code all along.
When are you talented folks going to stop pretending to be developing the best product you can for the Mac and go work somewhere where you actually can with real support from your management instead of lies and deceit for you and us, your soon-to-be former customers?
Get a backbone.

[…] Poor old Mac Excel, it just don’t get no respect. It’s different enough from PC Excel to strike uncanny valley fears into the unwitting. The next versions will exclude built-in VBA much to the chagrin of the Mac business faithful. The uproar reminds me of when Lotus announced it would pull LotusScript, a VBA-like language, out of its Notes program. People were openly revolting (although nothing was quite as revolting as Notes development). So, if you don’t have Parallels or the like it’s pretty much the only choice you’ve got on OS X. Sure, you can use Open Office, but that comes with its own peculiarities and incompatibilities. […]

It’s interesting that NeoOffice has announced support for VBA macros in the near future (see Since that’s open source, we will see exactly how they’re doing it. Note that NeoOffice is not just OpenOffice but a fork of OpenOffice with additional development going on. They have chosen to depart from the philosophy of some in the main development of OpenOffice and support Microsoft’s XML based formats right away.
My understanding is that there isn’t much of any reason to use assembly anymore. In the past, it was used for performance reasons. Now, not only are computers much faster but compilers are better and they produce code which is closer to the performance you get with assembly. It is also my understanding that JAVA, which is the language used in OpenOffice development, has better features than C++ when it comes to maintenance of large amounts of source code. C# presumably has similar advantages. It seems to me that MS Office development needs to move to higher level development tools or end up eventually falling behind in spite of Microsoft’s superior resources.
That brings me to the social/business side of the matter. It sounds to me like you, at the MacBU, are acting completely independently from the main development team of Office. You get information and source code but are you in on the planning? I remember how the MacBU got started, with freelance programmers chosen by Apple to fulfill the special deal made between Apple and Microsoft in 1997. It was a great solution at the time but it sounds like what’s happened is that Mac development has gone off on it’s own fork, starting with the port of Office 97 and has not really kept in sync with Windows development. Microsoft is going to have to plan Mac and Windows development together if there’s going to be real, ongoing support for Office on Mac.
One more thing of note. The blog post and several comments have mentioned the idea of the application being Mac-like. Before Office 98, Word 6 was widely criticized for not being Mac-like and I’m sure that was a major consideration in the effort to make Office 98 and it’s successors. The thing is that I think a lot has changed since then. A lot of those people who wanted applications to be Mac-like never made the switch from OS 9 to OS X and ended up switching to Windows (ironic but true). Others have been through some major UI changes in OS X and are now much more used to the idea of UI things changing all the time. Meanwhile, a pretty good chunk of current Mac users are recent switchers from Windows or Linux. The point being that Mac-likeness is not the same thing as it used to be and is not quite the priority it used to be either.

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.

Why not build a plugin interface/API that allows third-party developers to create scripting language interpreters that can interface with the Office apps in the same way that VBA did? Essentially, build a big gaping hole (with a lot of loose wires) that others could fill.
I’d love to be able to code Ruby inside Office, for example, just by calling the right things…

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.

Although I’ve used a Mac now and again, I spend virtually all of my time on the Windows size of the house. Whether I am in Mac land or Win land, I am a software developer, and I’ve been doing that for almost 30 years, which included a few years in product development for a commercial software company. Even in my consulting practice, I have faced similar decisions regarding the software that I maintain and distribute on behalf of clients.
In addition to my general experience, I was directly affected, very significantly, by a similar decision taken by the WinWord group when they released Office 97. Previous versions of Word for Windows included a macro language called WordBasic. It was a lot like QuickBasic for DOS, with a few extensions to support interaction with Word documents. I had production code, written in WordBasic, that was deployed in over forty locations on five continents. Since the client was deploying Office 97 world wide, and WordBasic was, for all practical purposes, going away, I had to rewrite and deploy a new version of the application template, and ensure that it was installed in every location as soon as possible after that location moved from Windows 3.1 and WinWord 6 to Windows 95 and Office 97. I had only a few months to learn the new language, rewrite the code, test it, and deploy it.
Was it painless? Of course not!
In late 1996, there was almost no reference material for the new language, other than the help files that came with Office 97. There were books, of course, but we were all still learning, and the book authors based their work on beta software, so some things didn’t quite work as expected in the production code that we had as the basis of our development and eventual deployment. There weren’t as many developer Web sites and bulletin boards as there are today, either, let alone blogs, wikis, and the other tools we have to distributing information about new software.
Was it worth the effort? Absolutely!
VBA included a much richer object model that gave us very fine grained control over the format of the documents. The whole language was much more modern, and was better suited to interacting with objects, not only in Word, but, in the right circumstances, in Excel, PowerPoint, and even Outlook.

[…] Basic for Applications en el que se escriben las macros en esta suite no será soportado por la versión para OS X. Por si eso fuese poco, la nueva versión de Office para la plataforma Windows implementa de forma […]

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 started writing applications for Word with version 2.0 of WinWord. I wrote one of the first books on wordBasic. I wrote some of the templates that shipped with Word 6.
I’ve been developing two major applications for Word since 1995 or so. ScriptWright and BookWright. They transform the Word interface into dedicated screenplay and book applications.
This is possible because Word’s fundamental design — moreso in earlier versions than in the most recent — rested upon the idea that NOTHING that could be done in the UI could not be addressed in the underlying programming language.
From the developer’s point of view wordBasic and VBA were not additions to Word, they were the essence of word. Combined with Templates and Add-on capability, they allowed a programmer to add features, change features — to completely change the interface.
The removal of VBA from WordMac is a horrible decision and should be reversed.
It matters not at all that it doesn’t communicate with other apple work flows. Neither did the original word basic without major surgery — like DDE and API addressing.
The point of vba is to allow customization of Word as much as it is to aid in interoperability.
The genius of the early releases of Word, and no small part of its victory of other word processors in the market place, was precisely this open architecture. It is frightening to see the MacBU give up on trying to match the Windows version. Just as it is frightening every time the Windows unit adds another feature that cannot be completely controlled and addressed from VBA.
Both units are infatuated with themselves and are not paying due homage to what made this product succeed.
I have tried, with each release of a Word for the Mac, to port my applications from Windows. In previous iterations (Word 6 and Word 98 under OS/9) I gave up (after no small investment of time and money). They just wouldn’t work cleaning.
I bought a new OS/X machine a little over a year ago. To my delete the conversion seemed to be progressing. And I recently released the first of my two major applications BookWright. Then I discovered that this is a one cycle success. Why bother with porting the screenplay application? My users will have to stay with Word2004 if they wish to continue with my product.
The suggestion that I can achieve the same results with RealBasic or Apple Script — well that is simply wrong. Those are layers outside of Word. My applications word from within and must do so. Similarly, the Windows unit is suggesting to developers to move to NET of VSTO. It just proves how little this generation of programmers at MS understand about the internals of Office.

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.

I completely agree that the first priority of Mac Word should have always been and should now be feature by feature compatibility with the Windows version of Word.
No matter how awkward the transition, Microsoft has the resources and the brains to make VBA work in MacWord — and has the ability to release feature mapped versions of the program on both platforms.
To contend otherwise is completely is, literally, incredible.
My suggestion to both the MacBU and the WinWord BU is that they hire some new guy to data mine through the old CompuServe MSAPPS forum — surely someone has kept a record of those early days when the DevTeam actually spoke with power users rather than focus groups — and try to recapture, re-imagine, the astounding beauty and functionality in the original WinWord design. That’s why WordPerfect was crushed. Why AmiPro and WordStar 2000 never had a chance. Word for Windows dominated PRECISELY because of the elegance of it’s design, because it was customizable, because you could make it do anything you wanted.
You guys have forgotten why you’re making this thing.

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.

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.

This is a real pain in the butt for me. I have developed a number of excel sheets and programs using VBA extensively on my Mac, for final use on XP systems. I dope someone will produce a converter of some sort as I will be stuffed by this decision.
The only other option I can see is installing XP version of Office to run under parallels, but I really dont want to have to buy Parallels, Windows and Office for windows.
Ok The decision is made, but perhaps a more suitable decision would have been for the Windows Office to be written with cross platform in mind. Maybe this could happen in the future, so the same version of office could run in Windows, Mac and Linux 😉

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!

Oh please!! Apple can get PowerPC code to run seamlessly on Intel chips and yet Microsoft in this blog says “it has turned out to be quite difficult” to find someone to port VB to the Mac!! What a flippin’ management joke. If I worked at Microsoft I would be embarrased for the MacBU management to play victim of this. Clearly, the management team doesn’t bonus the outstanding engineers well because I GUARANTEE you there is someone there that could get the job done.

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.

not that i understand any/all the technicalities but…
it does indicate to me that this creates a serious wedge petween the 2 platforms. mac’s next big growth market must be the mainstream business environment.
the only way for mac to make inroads there is to have FULL compatibility.
by not allowing this in the business tools companies use most, ms is protecting its windows turf. this is not a resource-allocation decision, this is a business strategy. it is very bad news for mac.
it emphasizes mac’s need to be ms independant and to continue to develop its own software.
i hope this decision comes back to haunt ms in a big way.

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

You know, this whole writeup is suspect to me – As the Intel lineup progresses, the performance hit from running Office 2004 with Rosetta will become increasingly mitigated. You could solve the whole damn problem if M$ released a patch for Office 2004 that makes it compatible with the Office 2007 file format, but of course, where’s the profit in that?

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 fought with Microsoft to include Office for Mac in my MSDN Universal (which wasn’t all that ‘universal’ after all) subscription because I had clients who used Macs AND PCs interchangibly. If I were to truly support the VBA code I delivered, a Mac environment would have to be there, and the promotional material for MSDN Universal proclaimed that it supplied ALL platforms that VBA was on. In the end, Microsoft shipped me a commercial box of the gold-level of Office 98 (if I recall correctly the version number) for Mac, perhaps just to shut me up. The fact that they did not natively include Office for Mac in that $3000+ product (MSDN Universal) shows to me that Microsoft was not committed enough to really being serious about building a VBA developer community for the Mac.
This post is amazing, by the way. Here we have a manager / leader / developer at Microsoft, a software DEVELOPMENT company, complaining how hard it is to build software! Duh. What should Apple have done for you, give you a big green button and volià here is your fully-functional and backwards-compatible VBA? Building something like VBA is not a trivial task at the best of times. Development is FAR more complex than it was when big Billy G. hacked against Microsoft Basic in the 1970s. To be retreating from the challenge, even though the bar is higher than yesterday, says to me that you are not up to the challenge, and perhaps you are not the right person / team / company to lead the way to tomorrow. To quit because something is hard is a cowardly response, and a way to certain defeat. You allies (all those developers you’ve heard from) in the trenches have been let down by your abandonment of the battlefield. Such a move, no matter how ‘justified’ is a choice that will have grave consequences for your business for years to come. You’ve given up the fight and abandoned ground you’ve invested years and millions of dollars in winning.
Time for a new general.

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.

From what I understand, you guys had three options:
– dropping VBA for Mac in the next Office version, even if this hurts a minority, but a loud minority of users – this is what you chose ;
– porting the existing code base, which is a technically hard thing to do, because an enormous legacy code which contains deep dependencies into obsolete assembler, PPC and windows code. You expect that porting to be outrageously expensive, and worse, to take two full years to complete, which is why you won’t do it.
– just rewrite the hole damn thing in a modern high level .Net language, get your-selfs or buy a nice modularized editor and build the interpreter in three months, and spend 6 months in testing as to pick compatibility errors.
I mean, two years to port an existing application, this just sounds like a communist apparatchik junta deciding over the fate of the old town bridge built in the 19th century, while blaming it’s architects for not forecasting 21st century’s trailers over it. This and that blog over how to build a desktop side bar in a three years period are just throwing lights over what has become a giant buraucracy, shame on you.

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.

Actually, there is no need to build the equivalent of a compiler into Office for Mac in order to deal with VBA macros. Nor is there any need to implement a translator.
1. Remove the PPC byte-code compiler/linker completely and discard
2. Create a simple byte-code to C translator, which emits each macro as a C function. Don’t worry about generating efficient C, the compiler (step 3) will take care of that.
3. Compile the macro(s) using your favorite (external) C compiler.
e.g. system(“gcc -O3 …”);
4. Dynamically link the compiled macro(s) to the Office executable.
e.g. dlopen(…);
5. Find macro function entry points and save in a suitable data structure.
6. Call the compiled VBA macro functions as necessary.
7. If feeling adventurous, embed the compiled object(s) in the Office document that contains the macros so that compilation is a one-time effort.
How hard is this? Worried about the cost of calling a compiler? It’s faster than you might think, and better than losing compatibility and all those paying customers. And if you need a hand – I’ve done this before.

Was there any follow up to this. I have no idea what your saying here but it seems if you found a possible solution that someone should say whether this is feasible or not?

Yeah.. It would be interesting to see if there was a follow up to this. I bet not.
This does sound like a really feasible solution indeed.
what about LLVM anybody at MacBU?? or use an OSA component, with VBA as its language of course.

It’s a shame that there are still such big differences between Office for Mac an d Windows. I work in the banking sector, and would love to see Macs being more frequent! Currenlty, to run a Mac while working in banking you would need a spare Windows machine as a backup for unknown problems.

You’re joking right? You don’t know anything about your only real competitor Open Office? If that’s true then you’re incompetent. If it is not then you’re a liar.
You’re definitely lying about it ‘not supporting the newer xml formats’. It already supports the only ISO standard XML format – ODF.

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.

Why couldn’t you make a Visual Basic to Applescript converter. Mac Office could open a document with embeded visual basic macros, convert the script to applescript, run it through the mac interface that they decided to implement instead, and you’d see little loss of functionality. For compatibility, the converter would work in reverse as well. Applescript macros written in Mac Office could be saved to Visual Basic macro format so that windows office could open it and still run the macros. Wouldn’t that be a far easier implementation than spending 2 years straight completely rewriting it? As long as the macros still work and are compatible, I doubt anyone would care that it’s not running on VBA.

I’ve read this explanation twice now, and basically it boils down to “I couldn’t be bothered”. Pathetic. You have removed basic functionality from a program and claim that this is an improvement I should be grateful for? Why not remove the ability to create plots, that would actually be much less destructive for many many users than what you have actually done. I have a huge number of alternatives, better alternatives, if I want to create pretty plots and pro-quality spreadsheet graphics. I have no alternative program to run all my macros (which include some incredibly complex and powerful data processing plugins). Doesn’t it make you feel sick knowing that you have spent years creating a useless program? Doesn’t it crush pride to know that you have wasted years of your life? You say that most macros are portable to AppleScript, but that only goes to show just how little you appear to understand about the way that many people use macros, and just how many highly complex macros are in daily use by a huge number of people around the world. What you have now is just a substandard finance-only spreadsheet program, and you have killed Excel as a serious piece of scientific software. So it would have been some work for you. Diddums. That’s what you are paid for. Have you any comprehension of just how much money your decision has cost users around the world, how much time, how much stress? So your manager was close to crying, awww… I have actually SEEN users cry when they realise just how crap Excel 2008 is. The chart wizard is fucked. The macros are fucked sideways. And you claim it is improved? Moron.

>What you have now is just a substandard finance-only
>spreadsheet program, and you have killed Excel as a serious
>piece of scientific software.
Are you kidding? Excel was never a serious piece of scientific software. The statistical community have published papers in peer-reviewed journals for years advising readers to simply not use Excel. Going back as far as Excel ’95, it’s been filled with statistical errors and failed numerous benchmark tests. Some statistical functions returned answers with ZERO digits of accuracy! Version after version after version these errors went unfixed to the point where subheadings in new papers about Excel asked “Does Microsoft even fix bugs in Excel?” Some of the “fixes” they eventually did employ merely exchanged one type of error for another, even when fully functional algorithms for these functions were widely available in the literature. At least one bug Microsoft trumpeted as fixed turned out to yield the exact same erroneous values when tested.
Meanwhile, some errors were found in the open source spreadsheet program Gnumeric. When made aware of them, the handful of part-time volunteer developers had most of them fixed within weeks. When the next version of Gnumeric was released, it passed all of the benchmark tests with flying colors while Excel continued to be riddled with errors! It got to the point that one paper declared that those working on Excel were simply unqualified for the task.
OpenOffice was eventually tested as well and had some errors, but far less than Excel. Unlike Microsoft, the maintainers were responsive to the results and worked to fix the problems… I guess open bug trackers and direct contact with developers have their purposes. While Excel 2010 has finally fixed most of the errors (some of which existed for 15 years!!!) there are other issues with Excel including nonstandard orders of operation and inaccurate documentation that still have statisticians recommending it be avoided. The major authors of these papers have decided that given the history Excel should never be used until Microsoft publishes for each statistical function the source of their implementation in the literature, a set of test data and evidence that the function passes the test (what they should be doing internally, but given that their new random number generator returned negative numbers during testing when it should only return positive and they were using an RNG method which as a reference implementation in the public domain, it’s clear they simply don’t test before shipment). Statisticians continue to recommend Gnumeric and Open/LibreOffice (with Gnumeric the best) if one needs to use a spreadsheet for statistical work.
These days, spreadsheets are really only relegated to being a “pretty print” mechanism for tabular data and for very quick, simple work. For data analysis and exploration (like the science function you cite) dedicated statistical packages are used – SPSS, Stata, but more frequently nowadays R. R has really become the new de facto tool in academia and science. It’s also open source and free (although commercial implementations do exist). Many papers nowadays include code published in R and made available on R’s package repository for instant use by R users. Its powerful mathematical language and publication-quality graphing capabilities combined with features like “Sweave” to produce PDF documents with embedded R scripts (for things like dynamically updated charts) and interactive shells make it a powerhouse and even publisher O’Reilly’s chief Excel author has declared that he thought he was a capable data analyst before (only using Excel) but after encountering R he realized how wrong he was and that he believes *everyone* needs to learn R. He also shares the sentiment that Excel is really only superior to R in tabular data presentation and quick work and recommends R now for everything else.
You also chose to implement your work in a closed, proprietary program using a proprietary language produced by a court-declared monopolist found guilty of predatory practices and abuse of said monopoly with a history of simply ignoring bugs in the product in question with no open bug tracker or way for users to even report bugs (while a web page can ultimately be found, it doesn’t even ask for the reporter’s e-mail address, making follow-up impossible and the reporting function almost useless since a developer can’t inquire for reproducibility, test data or provide patches for testing if data can’t be shared). On top of that, you used the software on a closed, proprietary OS with a recent history of increasingly locking down its own platform as well. Given all that – the wrong tool by the wrong company on the wrong OS – how can one honestly complain about being burned by a change??? That’s the price of choosing a sole vendor or a closed “standard” – you’re at the mercy of the vendor, and this vendor’s history is certainly clear (and the OS you’re running is a competitor to the company). Important data and work is too important to lock up into a proprietary product, much less one from a vendor with a monopoly, a bad history, and no love for the maker of the hardware its running on. That’s work that should have been in R, or even LibreOffice – which offers open standards javascript and python as alternatives to its own Basic language, preventing any sort of lock-in (neither can disappear).
Maybe people who use OS X don’t understand the harm large, controlling corporations with proprietary tech can do by definition (they’re choosing a walled garden after all), but that’s not the fault of Microsoft in this case. MS showed a disregard for good programming practices and openness by tying their product so completely into the chip and/or their own OS depending on the version we’re talking about, but those who used the product for serious work made the bet to engage in willful vendor lock-in with a monopoly and hope they didn’t get burned. They bear responsibility for getting stuck.

It would take you two years to rewrite the code? So what? It took me five years to acquire the knowledge to write applications which talked to each other in Office across Access, Excel, and Outlook, all of which use VBA.
And no one was paying me out of some corporate budget. I came to Macs late in life, but if I could, would drop the various PCs I have just because the Mac is a beautiful machine.
The arrogance of Microsoft, with its screw the customer attitude is mind-boggling. (you once tried to charge me £230 just to ask a question when I found a bug in Access which then you credited after you admitted it was your fault). This is just another brick in the Microsoft stonewall built with complete disregard of your customers and the work they put in to adapt your undoubtedly great parts of the package (Pivot Tables for instance) to good use.
A plague on your house.

Thanx, for your help. Actualy I have a excel with specific template. The excel file have a macro written in VBA attached with it. Whenever another user downloads that file that macro is executed. I want to write that same macro in applescript and attach it to excel as excel 2008 don’t have support for VB macro. Is there any way to execute macro written in applescript through excel 2008, so whenever another user download this excel file that macro written in applescript should be executed automatically and provides same functionality as macro in VBA. Please help me with this problem.
Thanx again.

I was a first tester of Excel 1.0 and I beta tested till 1993. I met some of the guys who wrote the formulas for excel. I actually prefer the old macro language and not vba. With add-ons I could make excel jump through hoops. SQL data-dipping was one of my favorites. You can’t tell me that providing the old macro language would be a big deal? Or providing an API and/or apple script-able commands to give me a fighting chance at providing a decent product to clients. Do MS executives look for ways to make Mac Users suffer or does it come naturally? I will of course have to use the PC version and run it in a Virtual environment, I just wish MS would do the right thing and stop selling a broken product!

I just installed Office 2008-upgrading from Office X. Unbelievable. I actually think that it is more difficult to take an otherwise useful program and make it completely worthless with an update than it is to make improvements. I can only guess that the team at Microsoft worked day and night to ensure that all cross-platform functionality in Excel was taken away. And I must commend the fact that it was so subtly done- I had no idea that VBA was not supported in this ‘update’. I don’t typically think to search on the web to be sure that an update is going to render my software useless. The first file I tried to open was toast. I actually try to use excel as a tool to get things done at work. I know, I know, all my colleagues say that that excel shouldn’t be used for real analytical work, but VBA made it possible- now Microsoft has proven them right with this update. Another great thing about this, that is so completely sinister, is that it is only the files that most likely took you the most time to make, and that are the most useful as tools that are now completely worthless. What next? I wish I could put into words just how incredibly epic this failure is, after reading this post I can see I can’t. You should all be ashamed of yourselves.

It`s all about money, protection and competition, on the back of customers that are made believe that updating is a thing you must do to keep in business.

Leave a Reply

Your email address will not be published. Required fields are marked *