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!)
-
Paul Topping,
Glad to see Design Science on here. Yes, EqnEditor (and Mathtype) along with EndNote are some big issues we need to address. Currently (even in Office 2004) there’s a pretty darn close to 1:1 mapping of VB and AppleScript to do what you need. There’s probably a few things missing so we’ll have to chat to see exactly what code you use. I’m sure we’ll be talking to you or other folks at your company extensively in the next few weeks.In the meantime, I plan to post some sample VB->AppleScript code snippets to show a little bit how things can be done. Perhaps next week…
-
These have been great posts, I always enjoy reading about the gory details behind the apps I use. There have already been a ton of unworkable suggestions, so I figured I might as well add mine. Since it seems OpenOffice is close to having VBA support and is LGPL licensed, what if you guys looked into adapting their VBA code into a library that Mac Office could link to? I’m sure that the OpenOffice community (and Novell) would appreciate the patches that would come out of your effort, and it might be a ‘cheaper’ way to implement VBA. I’m sure it would be all over slashdot.
Like I said though, I imagine it would be unworkable, and not that much better than starting from scratch. I know that the OpenOffice codebase is fairly monolithic and I doubt their VBA implementation is nearly modular/portable enough to be of use. Maybe it could work though… modifying their interpreter to send Apple Events to Mac Office or somesuch. I guess that would still leave a lot of unsolved issues even if it were possible though.
-
Reads to me like the result of a brain-dead design to begin with and understaffing.
-
Dependable, cross-platform compatability will in effect be dead. All I can say is thank goodness for the Intel Macs and Parallels. As a consultant who would prefer to use a Mac but needs to work with many corporate clients standardized on Windows, I will just be forced (as much as it will hurt) to keep a Windows VM running and make sure that any docs and spreadsheets that need to be exchanged with those clients are created and modified in Windows. Yuck!
-
I don’t know why you’d want to bother working on Mac Office at all with the amount of bile and abuse your subjected to in these comments.
-
Thank you for this behind the scene explanation. As a developer, I understand the technical chalenge of porting VBA to Intel. But as a user of Excel, I also understand that a majority of Excel workbooks contains VBA macro and so it is a huge losse for Office user and for the Mac platform.
Like Frederik Slijkerman in his two posts, I was ask to myself if you have explore the idea of parsing the VBA opcode with a VM written in C++. Having written several, It doesn’t seem huge job compare to written a JIT compiler. I’s more easy to debug and stabilize and also to port to several platform.
It’s the approach choose by OpenOffice (which has a Basic implementation but a different Object model than MS Office).
Concerning performance problem, it seems that today we don’t the need of a JIT compiler for VBA scripts. Machines are way faster than ten years ago.
In my job, I face the same problem as you: dealing with a old product (a development environment with a form editor, a language and a lot of assembly code). We choose another way to ports applications written with it: transcoding everything in Java. This implied rewritten old C code in Java. In fact, despite the higher level of abstraction, the execution was really fast). Quite usable.
And it was a great plus for the support team as it was easier to maintain a modern and well design code than an old and hack one…
The support of VBA could be supply in subsequent release of Office 12. This way, the users that need the most the VBA part of the compatibility would have a temporary solution: Office 2004 in Rosetta and a long term solution.
For now, they have no more solution… and has Mac users are not the most numerous, if they can’t execute important corporate Excel sheet, they will be forced to leave the platform or use Parallels and Office for Windows…
-
Matt said “It seems the responses are grouped into those from developers (who are understanding), and those from enterprise customers who, of all people, should understand economic reasons for not going ahead with VB support”
I don’t find this at all surprising. Developers have two reasons for being sympathetic. First, they acknowledge that the problem is difficult. Second, the solution chosen by Microsoft potentially means more work for them rewriting existing applications. Who wouldn’t be pleased?
Well the answer to that question is the second group – the enterprise customers who will have to pay for those rewrites. Microsoft is saving itself effort and money by passing the rewrite problem on to its customers. Those customers can of course avoid those rewrite expenses altogether by neglecting to upgrade to the latest version of Office. It will be interesting to see whether the resulting loss of revenue leaves Microsoft ahead on balance.
-
So, this is a result of years of incompetence: bad VB language design, bad coding practices? I guess these are also reasons why MS has such a hard time shipping.
But maybe this is just bullshit – writing a parser and interpreter/compiler is not really rocket science, even for a shitty language like VB.
-
There are those for whom compatibility is the only reason to use MS Office. What happens to them if said compatibility breaks? Their only impetus to use Office is gone and they find something else.
Ya really gotta face facts here: most Mac office users don’t use office because they love it or it’s the best deal around: they use it for compatibility reasons. Also, lots of businesses only tolerate Macs as long as Mac Office can read files created by Windows Office, and there’s always some gnarled binary file that TextEdit won’t open, or a graph or two that only Word can view. It’s all about compatibility here.
If this compatibility begins to break, then two things will happen: businesses will insist upon Windows simply so their business works, and those using Office exclusively for compatibility will turn elsewhere, plain and simple.
I understand that Mac-Win compatibility and Mac-like behavior are your two overrriding concerns, but there are some things that affect one more then the other. In the case of VB, compatibility is key, and no amount of Mac-like prettiness will persuade those forced to change their software, skill set, or even employment as a result of the decision to remove what allows this product to exist in many markets to begin with.
Suck it up. You wrote bad code in the 90s. Now fix it. Adobe did the same thing, which is why CS is still PPC only. They even said so–they’ve still got 68K code in their software. Fixing this mess will take time, skill, innovation, and motivation. Does the MBU have them?
-
Thanks for your post – I understand and believe your motives for dropping VBA. I still however feel that you underestimate the need for cross platform scripting in Office.
Mac users don’t use Office because it’s the most Mac-like solution, they use it because it’s compatible with Windows Office. For example, the text engine in Word is completely custom to ensure compatibility with Windows Office.
Providing applescript access to the VBA object model is nice, but it doesn’t in any way alleviate the need for cross platform scripting. Office is above all thing, a cross platform standard and the minute you guys move away from this you are failing in (what should be) your primary goal for the product.
-
Sad but true: The MacBU at Microsoft does not understand their main product nor their customers. Do they really believe that there are any other reasons than cross platform and backward compatability to buy and use MS Office?
VB is the not another it is the essential feature of MS Office. Without VB I can use any other app that can open or import plain excel docs. Why should I bother to buy MS Office?
But wait, they simply can not be that ignorant not even at MS. So what is the real reason? They want us to switch to Windows and the Windows version of Office. But this won’t work either. I will never run Windows on my Mac and I surely won’t buy a PC. So, after 10 years its good bye MS. Now I learned my lesson and will never buy anything from this company. No software no hardware no books. -
Thanks for the info/explanation. I find it reasonable and while I will miss having macros in Office, I’ll bite the bullet, learn AppleScript, and go on. I don’t share macros with Win users, so this isn’t (currently) an issue for me.
I do find much of the explanation surprising, though — things like ‘the source code doesn’t exist.’ It really makes MS look more like a skunkworks and less like a professional software developer.
I can’t imagine any of the suggestions I’ve seen so far working, at least not for the next version of Office, but I like the idea of including a copy of Win Office. Maybe a coupon the Mac user could mail in for a Win Office CD set if the need VBA support? Then they could run it under Crossover or Parallels. Not elegant, but acceptable to most.
I still remember a few years ago when the “it looks like you’re managing a list” feature started popping up. MS research showed that a large percentage of their users on the Mac side were using Excel like a database, so they added the feature. Why not? Windows users use Access instead of a real database, just because it’s there — why not Excel? Anyway, the point is that the audiences are very different. I’d guess a pretty tiny percentage of Mac Office users have ever touched the macro feature.
And on the bright side — killing VBA means no more Word macro viruses!
-
Enterprise customers’ anger is just another illustration how much they hate Macs and look for ANY reason to get rid of them. “Mac shops” where IT guys actually use Macs themselves would not have much problem with AppleScript, why would they? IT guys running PCs should stop wining and kick Macs out. That’s really what they are after, anyway.
I’m sure MacBU has the numbers to back the decision up. There’s no way the majority of consumer users doesn’t have Word / Excel on their computers. Too many incoming documents from PC users with MS Office pre-installed. Too many Word documents hanging on websites. No to mention there are folks that still like Entourage over Apple Mail (though I’m not one of them).
Thumbs up on the post, I’m not the biggest MacBU software user out there, but I have a lot of respect for you guys.
-
Thanks for the post and for your explanations. However I am very disappointed to hear of the demise of VBA for Mac. This will considerably affect Mac users in corporate environments. File and function compatibility is VERY important for corporate users.
Some examples of use: I have done a significant amount of VBA programming in Excel and PowerPoint over the years – most of this on the Mac to be used on Windows and Mac. This VBA stuff is used in various places in our company from timesheets (press buttons/choose from menu items to format, check, update database and prompt user), quality control of scientific data (automated plots including wind vector fields using arrows), specific complex functions like calculations of vapour pressures, potential temperature, etc. I don’t see applescript doing this (quite apart from the compatibility issues with Windows!!). VBA in Powerpoint enabled the merging and import of hundreds of matching gif file pairs into an endlessly repeating Powerpoint show for display.
Some suggestions:
- Run the current VBA code under Rosetta with the rest native until the VBA code is updated.- Contract out the VBA code update.
- Talk with (contract them) the “REALbasic” people to enhance/merge the “REALbasic 2006″ code and merge within VBA. Their website states that “REALbasic is highly compatible with Visual Basic, so Visual Basic developers are productive very quickly with REALbasic”.
So please, please reconsider your decision – for corporate users in particular compatibility is important!!!
-
And in the long term, VBA will be replaced by a .NET based version anyway and so for the next version after the next version, which will be presumably be Intel-only, how about porting the CLR to the Mac.
-
There’s discussion of the implications of this move over at the Mellel forum. This is what I posted:
I think the lack of VBA support will force most large organisations now using Office on both Macs and PCs to move entirely to Windows Office, because they typically rely heavily on VBA macros. No PC macros will work in the Mac version and no Mac macros will work in the PC version. Mac users may be allowed to run Windows Office on new Intel Macs, or they may be moved over to PCs, depending on the organisation.
What about home, academic and small business users? They will be aware of the trend for Mac Office to become even less compatible with Windows Office than it is now. Anyone who needs full compatibility will have to buy Windows Office, as you do now if you need proper support for multiple languages in Unicode. The difference from now is that by next year a lot of people will have Macs capable of running Windows Office at native speeds. To some extent, then, the next version of Mac Office will be just another Mac word processor, competing with Mellel etc. on features and ease of use, rather than being an automatic choice as it is for many people now.
I don’t use any VBA macros in Office (except maybe the Bookends toolbar), but I doubt I’ll bother to ‘upgrade’ to the next Mac Office while I’m still using a PowerBook. And when I — eventually — get some kind of MacBook, I’ll probably get Windows Office so I can be sure that files I am sent look exactly how they should. I don’t know how typical I am, but I suspect a lot of home users will not upgrade and others will move to Windows Office on Intel Macs. Together with the demise of Mac Office at most businesses, use of Mac Office may seriously diminish over the next few years.
All of this puts the next but one version of Mac Office (Office 2009?) into serious question, I think.
-
Can we have a basic C++ api, well documented, for adding our own spreadsheet functions. The Excel 97 SDK is very easy to use in Win32 land.
-
The only reason a lot of Mac users still use Microsoft Office is to ensure compatibility with a lot of people who run the suite on Windows.
Compatibility by all means includes VB macros. We need to open those files, use them as they are, and save them. I’ve personally written Excel macros (on Windows) that are absolutely essential for using the document in question. Without the macros, there’s no point in even opening the document. Rewriting scripts in AppleScript is absolutely, positively out of the question.
Microsoft needs to add the functionality later if it is to maintain the Mac user base. Otherwise, Mac Office will very simply not be compatible with Win Office. There’s no other way of putting it.
Thanks for the explanation. However, it’s Microsoft that we’re talking about. Compaining about the lack of resources will do little to ease the discontent. I understand that the Mac BU is probably not to blame for this, but it would be difficult not to transfer the blame to greater Microsoft.
-
“VBA is basically a compiler that emits code at runtime” – so, it’s an interpreter? That’s hardly an unsolved problem. I agree you wouldn’t want to touch the existing assembly code from either code base. I guess the other option is a language translator – maybe you could implement the opcodes in something like javascript (for which you already have a MacBU virtual machine from your explorer code…)
The forms stuff on the other hand sounds like a developers nightmare. I’m a developer and I feel your pain!
Your arguments all make perfect sense as to why VBA won’t be in the next release of Mac Office. The only argument that makes sense about why you would not then re-introduce it in a future version to re-attain parity with Win Office is to help corporate IT departments stamp out those Mac outposts in marketing that they hate so much.
Further to someones previous comment about Word 6 – the current MacBU approach is SO much better. Mac Word 5.1 was honestly one of the best word processing applications ever. If I could use that on a current Mac with support for current file formats I would. Maybe put modern table handling in it, but that’s all.
Having said that, it makes me think. Those (misguided) Word 6 developers could make a Pcode interpreter work on both platforms with reasonable performance on very limited machines. VBA is surely a much simpler proposition?
That also makes me think. I just finished listening to an interview with Microsoft’s Bill Hilf about Open Source at Microsoft. If you are truly going to abandon it – why not publish the VBA specs and the Mac Office plugin specs and see if the Mac community doesn’t come up with a solution. Much like the Win Office team did with the ODF plugin (If you were able to put some money up like they did then that would be even better).
-
Pingback from Sylvain v2.0 » on August 23, 2006 at 3:18 am
-
As a long time user of Mac Office 2004, I can say that I’m gald that MS Office is being ‘ported’ to Intel OS X. I depend on it and the compatibility with Office for Windows is pretty good. However, let me just say that I’m really looking forward to the new version compiled in XCode. PPC Office 2004 has never really felt like a native app. It is slow, choppy, and eats CPU when doing absolutely nothing, especially when in the background. The scrolling is even choppy and jumps from page to page as soon as I have graphics inserted and the word doc is more than a couple of MB (even on a G5). How hard could it be to fix the scrolling? As someone who is not a developer and doesn’t really know what he is talking about, PPC Office 2004 feels pretty much like universal firefox: looks and runs alright but definitelely doesn’t feel like a native cocoa app. While I understand the effort needed to port to XCode, hopefully the final product will be well worth it. And yes, the inclusion of OS X technologies like Automator is killer.
-
Oh boo-hoo… That’s a whole lotta words to roughly state what George W Bush did in defending his own administration’s abysmal failures. In that case, three words summed it up:
“It’s hard work!”
What seems to be increasingly hard for Microsoft is giving customers an actual reason to consider upgrading. The ongoing trend of breaking existing applications in order to generate churn is apparently the only viable strategy left, given the state of “good enough” was achieved to most folk’s satisfaction some years back.
The one thing OpenOffice offers, that I and millions of others are convinced Microsoft can never offer again, is Trust. Y’all have blown it all to shreds, and continue to show absolutely zero understanding of that simple fact. The only justifications offered anymore are cost/benefit, but in every case those are stated from your perspective only. It’s long past time to realign the sights, and once again consider the costs/benefits of and to your customers!
-
Any idea how many academic & scholarly writers “out there” use Word + EndNote? Nor have I; but I do know it’s at least 80% of those I know. Without VBA, EndNote is useless. Without EndNote, Word (for that user group) is useless. I would expect this inexplicable (despite your sterling efforts to explain it) decision will cost Microsoft and Thompson most of its customers in the next cycle.
See, what we have at the moment, on Intel Macs, is a situation where Word is slow as syrup and EndNote is struggling (has been for years). What we *will* have is a situation where Word is okay but EndNote is useless. I woud predict a slow but ineluctable migration to Mellel plus Bookends/Sente: already two first-rate combinations and ones which, I suspect, Microsoft have just given some considerable traction in this market.
The short summary is this: many only use Word because it works with Bookends. When that stops working, game over.
-
Correction: I said “The short summary is this: many only use Word because it works with Bookends” I meant, of course, EndNote.
-
The loss of visual basic is a non-story to me. I have used Office since 98 and have become increasingly disenchanted with it. If MS has to dump a component of Office to make it better that’s great. In my opinion there are a lot of better word processors and presentation applications for the Mac than office. My only concern is a replacement for Excel. My biggest complaints with MS is that they won’t use, or give me the option to use, the features of OS X such as address book and iCal. I have to maintain a seperate address book and calendar if I want to use Entourage.
-
You appear to be locking yourself to Apple tools, when “Intel is your friend” in this matter…. compiler and cross plat work…
-
Why not write a VBA2Applescript translator ?
Release it as downloadable freebie for Mac and concentrate on Applescript support in Office 2007.
-
I have invested literally hundreds of hours in thousands of lines of VBA code that perform custom text-parsing operations on MS Word documents. By pulling the rug out from under all this work, and destroying the value that it brings to my clients, when there are reasonable alternatives (as suggested in other posts), Microsoft is demonstrating its contempt for its own customers. Word 2004 is already extemely slow to update the display after editing operations (on my 2.1GHz G5), and VBA has been the only reason to put up with that. Mac users who don’t need VBA already have other word-processiong alternatives; it’s the power users who are willing to shell out for Office, and these are precisely the people you will alienate most by following through on this decision…
-
Well- my first question is, where is this information (dropping of VBA) generally available to the public? I have a huge WORD VBA-based application that I’ve had in distribution for 5 years (now at version 6) I can’t even save the template on an intel Mac, but searches of the Mactopia and MS support sites have turned up nothing. The FAQ section on intel Macs at Mactopia makes no mention of VBA, so that says something about MS’s opinion of how many people it might be important to. Unfortunately, for my clients, this will probably mean the abandoning of Macs, as it’s pretty hard to justify purchasing and maintaining two OSs for each machine.
Bill Spencer
-
Lack of Visual Basic in any version of Excel basically makes it useless to me. I have access to Excel on both Macs and Windows PCs. I do my work on a Mac because Windows just feels wrong to me. I don’t like sitting at a Windows machine. However, the rest of my company and our customers almost universally use Windows. I have developed some spreadsheet forms with very complex Visual Basic scripts. These are sent to our customers who must run them on the Windows version of Excel. Having different scripting languages on the Windows and Mac versions of Excel basically makes them separate and incompatible applications as far as I am concerned. I would frankly prefer to develop Applescripts but it is not an option. Instead of going further down the Excel path this decision by the Microsoft will make me convert the Excel spreadsheet that I use to collect information from customers to web based database methods instead. It’s been years since I’ve used Filemaker Pro. Time to get a new copy?
-
This is great news. The death of Mac Office.
Basically what this means is that all the employees at the MBU at Microsoft have just made sure they won’t have jobs in 2 years.
Microsoft made the Zune, can’t they get VB to work? Oh, forgot the Zune is stupid as so goes the MBU. The Zune and MBU will go down together. Whoever was in those planning meetings in the MBU, you should all just look at yourselves and think WTF did we just do, we killed mac office and our own jobs. Just such a bad decision.
-
Great read. My gut feelign tells me that someone at the top of the Microsoft food chain decided that it is time to kill Apple, the iPod, and anything that will make Apple a continued thorn in their side.
Won’t work though. Stay tuned.
-
Yes, that big unstable goon Steve Balmer, said enough is enough, Apple is making me look more stupid every day. End it some how, someone change the subject. Yea, no more Mac Office, that will get everyone afraid again of Apple going out of business.
Everyone… it’s Steve Blamer, the goon that can’t make one good product. It’s too bad the only good software unit at Microsoft is now being hog tied by the Balmer.
-
well, for me thats saying goodbye to office than. Excell is my real need, and you just killed it.
-
Ack! I just saw the news on MacCentral.
VBA, for all its quirks and bugs, is one helluva tool.
After you’ve built up a library of dozens and dozens of useful ’snippets’ and assigned them to menus and buttons, you can (I swear) improve your productivity in Excel by an order of magnitude. I can literaly do stuff in Excel in 10 minutes that would take an average Excel user a day or two.
And I have used Excel’s VBA to write thousands of lines of code for our staff. I cannot tell you how many times one of our finance or admin people has groaned and said, “Oh crap. Massaging this Excel page to get what the CFO wants will take me all afternoon.” I show them a few tricks, put a few bits into VBA, and presto, after 15 minutes we have what they need and something they can use in the future, to boot.
The folks above are right. If VBA isn’t available for the Mac, I’ll certainly stop using Office for the Mac.
More importantly, though, I’ll stop helping the PC Office users at work. I’m a busy guy. I do a lot of this VBA work at night after the wife and kids have gone to bed. Like so many of you, I use a Mac at home, but am forced to use a PC at work.
And once I’ve stopped helping the Excel PC users at work, their productivity will drop dramatically.
And, once that happens, I’ll get a call from our IT guys (like I do every couple of years) and they’ll say, “Hey. What just happened?”
And I’ll say, “Microsoft screwed us again.”
And they’ll say, “Yup. Just like last time.”
And then we’ll all go out for a beer and laugh at how we fell for it yet again.
Sometimes it’s really true that for want of a nail a kingdom is lost.
VBA is that nail.
-
I’m sure there is a better way. Instead of re-writing the Windows code to conform to Apple ABI, just make a wrapper that converts one type of call to the other. I mean sheesh, people have made Windows programs run on Linux for goodness sake. And instead of hand converting MASM to NASM, write a tool to do it or hack NASM. I mean, I used to work for a company that executed the exact same Intel binary code on three different OSes, DOS, and two flavours of Unix. How? By writing a small custom loader that loaded it into memory with differing shared libraries linked at runtime. There are so many ways to skin this cat, and a company with the broad technical skills of of Microsoft should be able to figure it out.
-
I feel compelled to point out that if any of my programmers came up with a design like the one you describe, I would have them fired on the spot.
How long can microsoft go on just putting out fires like this?
-
“A couple of months ago I wrote that I hoped my blog would help people trust the MacBU a little more”
If anything a decision like this makes me trust MS even less. MS seems to be out to screw mac users every chance they get, axeing Windows Media Player, IE, gutting features out of Office to make it less compatible with the Windows version.
-
Joseph Blietmann, STFU!!
-
Well, I use macros in Excel all the time. In fact, that functionality is the only thing that has kept me tied to Excel. I’ve been very curious to at least try the OpenOffice solutions and now I see no reason not to.
Secondly, I understand that porting VB would be a lot of work. Unfortunately, the decision that your team has made is pretty much the same as: “Hey, let’s take the bold, underline, and italic functions out.” Sometimes things just have to be there regardless of the work and cost. For me and thousands of other Mac users, VBA is one of those things.
Disappointing to say the least.
-
And one of the posters up above made a really good point:
Apple has made Mac Office 2004 (including full VBA functionality) run on Intel via Rosetta. Why can’t that be done in the next version of Office? Keep the VBA components compiled for the PPC architecture and let Rosetta emulate them while the rest of Office runs natively.
Certainly that would involve some coding and creativity, but it has to be possible.
-
I expect in the next few years you’ll be able to ALT+TAB over
between Windows and OSX, perhaps in Leopard, or in a post-leopard
system once Intel and Cupertino get their collective heads round hypervisors.
surely will happen in the next two to three years.If you’re M$, why develop for two platforms? You can sell (licenses for)
Windows XP/Vista AND Office PC to a Mac that dual-boots or runs a hypervisor,
but you’d only get one sale for a Office ‘Mac Edition’ that runs Aqua / Quartz.In 1996 it probably was necessary to compile into assembler on the fly and do all sorts of nifty tricks for performance reasons, (in 2006 CPUs, disc and RAM can tolerate a less efficient re-implementation) but the blog makes clear that putting VBA on Intel macs would require a year or more to write, quality assure and make stable if MS did it in house, or it would require a buy-out or collaboration with a third party such as REALbasic. Either way it’s not going to be immediate.
There’d be only a limited opportunity to recoup that expenditure in sales before the underlying technology made the duplicate work irrelevant, so it makes sense to bandage things as best possible.
-
I appreciate the explanation behind terminating VBA. It must have been a rough one. For those of us who depend on this functionality, it will push us to other options.
While VBA support in Office 2004 helps with a semi-seamless transition between Mac / Win Office, I’m finding myself using my VM more and more in Office 2003 on XP via my Mac. The bottom line is that for corporate applications utilizing VBA, I’ll have to live in that VM. However, I will continue to use and support Office for Mac as I find Entourage to be a DRAMATIC step above Outlook. Kudos for the thought and design of that product. I hope that the next version continues to be leaps and bounds ahead of the Win / Outlook platform.
-
Amazing. We’ve arrived at version 11 of MS-Office with full backward compatibility (mostly full anyway). We’ve had cross-platform compatibility since at least 1998. Compatibility was always a core MS tenet. It’s really a slap in the face to scientists, educators, students, and business people who have been loyal to the Mac BU. I think there’s nothing wrong with making Office more Mac-like. But not by cutting out functionality that has existed for the past 2-3 versions.
Perhaps the “correct” answer here will be some combination of porting AppleScript to OSA for Windows, opening up Office 2004’s VBA code to the OSS community, and creating a more open platform out of Office for the Mac.
-
Can a unified file be created?
By that I mean, first, can a single word or excel file hold a complete set of both mac and pc macros, will both platforms round-trip all macros they know nothing about, and can each platform add similar macros to the file without interfering with the other platform?
Such an ability would not make life easy or reasonable for the average user, but it would allow those few situations where a major piece of functionality is built into important enterprise office docuements to continue to function, with each customer being able to decide if the extra version (mac) is worth writting and maintaining based on their own dependence on the mac platform. Most will make the decision not to do such a thing, since in the long run it can only lead to incompatible behavior anyway, but many mac centric companies would need just such an ability.
It seems Mac Office primarily exists in the marketplace due to compatibility. Heck if you read your own history you will know that excel only ousted Lotus by being completely format compatible. If you don’t have sufficient compatibility then you will be competing on the mac platform on mac-native features and look-and-feel. Interestingly you get that fairly well most the time, and in fact have a better user experience than the windows version of office, but there have been many products Mac office has defeated in the past solely due to your compatibility, and such conpetition will occur again, inevitably.
-
What a whitewash…
It’s amazing to me that M$ can produce 11 generations of VBA enabled Office releases and not be able to do the next generation because “GCC is picky”. I love how the MacBU guys are actually justifying throwing away their jobs iwth a straight face.
Ben
‹ Previous · 1 · 2 · 3 · 4 · 5 · Next ›
208 comments
Comments feed for this article
Trackback link: http://www.schwieb.com/blog/2006/08/08/saying-goodbye-to-visual-basic/trackback/