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:
- it must be as Mac-like as possible, use Mac features, and take advantage of the Mac operating system, and
- 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!)
-
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.
-Josh -
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.
-d
-
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.
William
-
Pingback from Microsoft lägger ner Virtual PC - 99mac on August 9, 2006 at 1:09 am
-
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?
Thanks!
Shahram -
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 http://www.realsoftware.com/users/productivity/officeautomation/ “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.
Joshua
-
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.
-
Office Mac has been killed, the world doesn’t know it yet.
-
Pingback from Kernel Mustard » Blog Archive » Some randomness on August 9, 2006 at 1:11 pm
-
“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.
-
While I appreciate updating your old code must be a lot of work because of the old crufty code (2 years work even), dropping it completely seems a step too far.
For those of us considering if OpenOffice.org is where to go next, Novell announced VBA support in OpenOffice.org and here’s some screenshots to prove it…
http://reverendted.wordpress.com/2006/07/03/openofficeorg-and-excel-vba-macros/
-
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 was planning on using Excel for Windows via Parallels or something similar, as a key Excel tool I use http://www.bpmglobal.com
is only available for Windows.But I am “Not happy Jan” (its an Australian joke) about this.
-
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.
-
Hmm.
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.
-
“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. -
Pingback from Craig Maloney » Saying goodbye to Visual Basic on August 10, 2006 at 3:44 am
-
Just out of curiosity, difficulties in working with gcc are cited frequently.
What advantage would there be in working with the Intel compilers, since these will work with Xcode anyway? Intel already provides some tips for Xcode users (http://support.intel.com/support/performancetools/sb/CS-022350.htm)!
-
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.
-
OpenOffice.org
Anyone who may have Xls files containing macros, if you would like to help Novell to improve support in OpenOffice.org, you can send them our way. Michael Meeks’ team at Novell is looking for macros that they can test in order to refine OOo’s support. Send to thaeger AT novell DOT com.
Thanks,
Ted -
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.”
http://www.codeweavers.com/products/cxmac/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?
207 comments
Comments feed for this article
Trackback link: http://www.schwieb.com/blog/2006/08/08/saying-goodbye-to-visual-basic/trackback/