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!)
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.
Pingback: Why Microsoft dropped VB for Office for Mac at Aaron Adams’s Lame-ass Blog
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
Thanks.
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’..it 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.
Pathetic.
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.
CK.
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.
Pingback: The MTEQC Notes: Macintosh talk, tips and tricks.
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 ? ?
Guess I won’t worry about getting a UB version of Office… I use Pages for my personal stuff anyways.
excel – vb = 0 worth
Thanks for all the comments. I encourage folks to read my next post and consider giving us more specific actionable feedback.
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.
Pingback: Alea jacta Ouest » Visual Basic no more…
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.
http://www.dessci.com
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.