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!)
Say goodbye to visual basic and hello to Visual C++ Express.
One of the disadvantages of Visual C++ Express 2005 is the fact that it does not come bundled with 64 bit compiler support. Now if you have a 64 bit server or workstation you’ll likely want to compile your own 64 bit binaries. I figured out a way to do this using the Platform SDK. Check it out.
One of the main advantages of 64 bit processors is their ability to allocate more than 2GB of memory for a process, and its free to build 64 binaries for windows now.
I have serious problems with your explanation.
As far as I understand, VBA is a scripting language, the only thing you HAVE to provide is a faithfull converter/interpreter and the featureset.
The fact that the old VBA represented braindead coding, should not in any way excuse that you shuold be unable to implement the featureset in a more robust way today. Yes, it would be a big job, it would maybe have to wait to AFTER the lauch og Office -08, but there should be a number of ways to make a working solution , including spawning VBA out as standalone application on Rosetta or some trick using VPC and teh Office-07 codebase…
Mac Office is the key component for me to use a to enterprise. And the REASON for it beeing key, is VBA. I can use Openoffice and Pages and any spreadsheet kan replace Office as long as it is able to work with VBA.
A couple of years ago, Exchange exploded in enterprise. Since the internet features of Exchange at that time was a securityhole the size of a supertanker, noe proper exchange administrator wanted to run them. At this exact moment MBU choose to remove the Outlook klient and replace it with a internet protocoll only version.
Now Exchange works somwhat better and exchange admins slowly start to accept imap access, and then we suddenly get hit with this!
Yes I know I sound paranoid, but you have to admit that I have a pretty good Reason.
So please, please for the love of God, save me from the hell of Windows. I’ve been there, I tested Vista, I do NOT want to go back there again.
Get VBA working and put it in a servicepack!
(By the way, please break in at the exchange group and steal the exchange protocoll and implement it in Entourage. My Exchange Admin doesn’t trust you yet, )
All explanations and whining about challenges aside, it is not acceptable to eliminate a technology in Mac:Office that is still supported and in wide use in a previous version of Mac:Office and in previous, current, and future versions Windows Office. All your dissembling does not make sense any more than the thin excuses as to why you could not start OOXML converters until Window Office 2007 was final. Obviously the Windows team could work with non-final code all along.
When are you talented folks going to stop pretending to be developing the best product you can for the Mac and go work somewhere where you actually can with real support from your management instead of lies and deceit for you and us, your soon-to-be former customers?
Get a backbone.
Pingback: » Rodney Dangerfield of spreadsheets - Juice Analytics
It’s interesting that NeoOffice has announced support for VBA macros in the near future (see http://www.neooffice.com/). Since that’s open source, we will see exactly how they’re doing it. Note that NeoOffice is not just OpenOffice but a fork of OpenOffice with additional development going on. They have chosen to depart from the philosophy of some in the main development of OpenOffice and support Microsoft’s XML based formats right away.
My understanding is that there isn’t much of any reason to use assembly anymore. In the past, it was used for performance reasons. Now, not only are computers much faster but compilers are better and they produce code which is closer to the performance you get with assembly. It is also my understanding that JAVA, which is the language used in OpenOffice development, has better features than C++ when it comes to maintenance of large amounts of source code. C# presumably has similar advantages. It seems to me that MS Office development needs to move to higher level development tools or end up eventually falling behind in spite of Microsoft’s superior resources.
That brings me to the social/business side of the matter. It sounds to me like you, at the MacBU, are acting completely independently from the main development team of Office. You get information and source code but are you in on the planning? I remember how the MacBU got started, with freelance programmers chosen by Apple to fulfill the special deal made between Apple and Microsoft in 1997. It was a great solution at the time but it sounds like what’s happened is that Mac development has gone off on it’s own fork, starting with the port of Office 97 and has not really kept in sync with Windows development. Microsoft is going to have to plan Mac and Windows development together if there’s going to be real, ongoing support for Office on Mac.
One more thing of note. The blog post and several comments have mentioned the idea of the application being Mac-like. Before Office 98, Word 6 was widely criticized for not being Mac-like and I’m sure that was a major consideration in the effort to make Office 98 and it’s successors. The thing is that I think a lot has changed since then. A lot of those people who wanted applications to be Mac-like never made the switch from OS 9 to OS X and ended up switching to Windows (ironic but true). Others have been through some major UI changes in OS X and are now much more used to the idea of UI things changing all the time. Meanwhile, a pretty good chunk of current Mac users are recent switchers from Windows or Linux. The point being that Mac-likeness is not the same thing as it used to be and is not quite the priority it used to be either.
I only learned today from MacFixit about the end of VBA support on the Mac. What terrible news! I cannot imagine any reason why I would upgrade from a Win-compatible version of Office to a Win-incompatible version.
Inter-platform compatibility is critical, and making Office more “Mac-like” is nothing more than nice. In fact, I confess to not knowing what it means to be more Mac-like, in spite of using the Office suite on Macs since 1988 and on Windows since 1993.
For years columnists like Walt Mossberg of WSJ have advised readers there is no issue in switching from PCs to Macs because of file compatibility in Office applications. In the future there will be a big caveat. Even if they don’t completely understand, people will be wary, as well they should be. In my own case, as it becomes time to replace our Macs, the lack of compatibility (and the lack of VBA functionality) will provide strong incentives to switch to PCs. At home we have both Macs and PCs, and use both with Office files from work that contain macros.
Is the problem that MS corporate won’t give the Mac BU resources to ensure VBA compatibility? If so, one wonders if the MS strategy re. the Mac is similar to its strategy re. Java: “Embrace it, extend it, and extinguish it.” I know that’s not your motivation, but as a Mac BU business decision, it just doesn’t make sense to me.
Thank you for going into detail about the difficulties of porting VBA to Mac-Intel. I certainly can’t comment on specifics or offer suggestions on how to do it, but you did convince me that it is very hard. Still, from my point of view, ensuring complete inter-platform compatibilty should be a higher priority than anything else, and is certainly more important than implementing new features. Even if MS didn’t invent spreadsheets, I’ve long believed Excel is the greatest software package ever developed. The business problem for MS is that it’s so great, that any improvements at this point are marginal, and to many, if not most users, the benefits tend to be offset by the investment of time in getting up to speed. Still, we usually upgrade in order to have the latest, greatest version. However, unless and until you reverse the VBA decision, this time there will be a huge penalty for upgrading, and it is simply inconceivable to me that whatever the possible improvements, they would outweigh the giant negative, even if the upgrade were free.
Why not build a plugin interface/API that allows third-party developers to create scripting language interpreters that can interface with the Office apps in the same way that VBA did? Essentially, build a big gaping hole (with a lot of loose wires) that others could fill.
I’d love to be able to code Ruby inside Office, for example, just by calling the right things…
Sounds to me like the real problem is that VBA has become such a kludgy house of cards (which does happens after something like 20? years of ongoing development), that you folks really need to do what Microsoft did with Windows NT: scrap the whole damned thing and start over using modern programming tools to generate maintainable code. That’s substantially easier than trying to fix what barely works and what nobody really understands anymore (witness your comment about no longer having the VBA 97 source code).
Your comments about the quantity of assembly code still living in VBA are a sign of outdated programming approaches: modern hardware is amply fast to run VBA without such tweaks. Sure, it’s not so fast, but at least it works and can be maintained — when it stops working, at least you’ll know why. Isn’t it time you stopped hacking assembly code and left that to the compiler developers?
I’m encouraged that you’re making Word more Applescriptable, and so long as you give us hooks into all the interface features (menu items and dialog box widgets), we shouldn’t have any impossible difficulties in automating Word. The lack of cross-platform compatibility will be a real problem for some of us — a deal killer for some. Have you considered asking Apple how hard it would be to port Applescript to Windows? Look… it runs already on an Intel chip, so how hard could it be to tie it directly into Word under Windows? Seriously, though, why not ask? Apple has been keeping OS X parallel on Intel and PowerPC chips for many years now, and maybe they have an Intel-based Applescript you could license for this purpose. You won’t know until you ask, and don’t forget: Apple knows how important Office is to Mac users. They’d have a strong incentive to cooperate on this with you.
I’m also encouraged that you understand the importance of bug fixes, but am disappointed that you folks are so hung up on adding new features to Word (e.g., that damned “ribbon”) while breaking things that worked just fine already (menus) that you’re ignoring longstanding bugs that everyone knows about — such as the fact that autonumbering hasn’t worked since roughly Word 6, and that you could fix it in 5 minutes using the {SEQ} code approach that is well known in the writing community and well supported by all versions of Word that I’m familiar with. Then there’s the persistent bug in which revision tracking forgets the user identity, meaning that you can’t edit your own edits without having these tracked as changes by another editor. That’s a cross-platform bug, by the way — it’s bitten me and many others in several versions of Word on both platforms.
I don’t know how much “pull” you have in saying how things are done, but I do encourage you to think about some of the things I’ve said. You have some idea of the grief you’re causing your community of users. Use that to help make Microsoft more responsive to real user needs and less driven by the need to sell new versions. To be blunt, many of us who are still using older versions of Word are doing so because we’ve grown accustomed to the bugs in those versions and aren’t willing to sacrifice our hard-won skills and tools to upgrade to new versions that don’t fix the old bugs and that break features we rely on. If you’re going to pull a trick like the ribbon, at least have the courtesy to leave the old interface available for those of us who have mastered this. You did that in Word XP and 2003, and I encourage you to keep doing that in the future.
And while I’ve got your attention? I’m not going to upgrade for new features of questionable value, and irrespective of what your market research tells you, neither are many other readers. I was vastly amused by your advertising campaign comparing users of Office 97 to dinosaurs. Did your marketeers ever stop to ask themselves why we dinosaurs don’t upgrade? Give us a new version that fixes all the old bugs, that doesn’t eliminate our old tools and obsolete our old ways of working, and hold off on the features and I’ll upgrade in a second. I bet I’m not alone either!
All bitching aside, I _live_ in Word, and can’t imagine working without it. I wouldn’t take the time to bitch if I didn’t care.
Although I’ve used a Mac now and again, I spend virtually all of my time on the Windows size of the house. Whether I am in Mac land or Win land, I am a software developer, and I’ve been doing that for almost 30 years, which included a few years in product development for a commercial software company. Even in my consulting practice, I have faced similar decisions regarding the software that I maintain and distribute on behalf of clients.
In addition to my general experience, I was directly affected, very significantly, by a similar decision taken by the WinWord group when they released Office 97. Previous versions of Word for Windows included a macro language called WordBasic. It was a lot like QuickBasic for DOS, with a few extensions to support interaction with Word documents. I had production code, written in WordBasic, that was deployed in over forty locations on five continents. Since the client was deploying Office 97 world wide, and WordBasic was, for all practical purposes, going away, I had to rewrite and deploy a new version of the application template, and ensure that it was installed in every location as soon as possible after that location moved from Windows 3.1 and WinWord 6 to Windows 95 and Office 97. I had only a few months to learn the new language, rewrite the code, test it, and deploy it.
Was it painless? Of course not!
In late 1996, there was almost no reference material for the new language, other than the help files that came with Office 97. There were books, of course, but we were all still learning, and the book authors based their work on beta software, so some things didn’t quite work as expected in the production code that we had as the basis of our development and eventual deployment. There weren’t as many developer Web sites and bulletin boards as there are today, either, let alone blogs, wikis, and the other tools we have to distributing information about new software.
Was it worth the effort? Absolutely!
VBA included a much richer object model that gave us very fine grained control over the format of the documents. The whole language was much more modern, and was better suited to interacting with objects, not only in Word, but, in the right circumstances, in Excel, PowerPoint, and even Outlook.
Pingback: MacGuild.org » Blog Archive » Apple Worldwide Developer Conference 2006 Trip Report
Pingback: VacioPerfecto
I am going to buy a mac, stands-whether?
I wait for advice. In advance thanks.
Seems like a monolopy is abusing it power. Let the lawsuits begin.
Gosh! This post just made me mad as it doesn’t change the reality which will be created from this inconceivable decision.
VBA is still a core part in my business and the fact that I can write VBA macro on my Mac is the most important excuse why I can use Mac in my company where most of the people use Windows. This decision simply suggests me to buy Parallel, Vista and Office on Windows instead of new Office on Mac – something I personally hate to do.
I don’t make any comments on technical difficulty of importing VBA to new Office on Mac. I definitely prefer waiting for two or three more yeas for the new Office on Mac with VBA to waiting for a year for the new Office without VBA. Reducing crossplatformability is simply nonsense.
Pingback: RazorSharp iPods & Raw Gadgets » Archive » No Visual Basic in Office 2008? No thanks.
Well… I was waiting to see what handicap would be introduced with the new Mac Office suite. Now we know. I’m afraid this is a deal breaker for me. The only reason I use Microsoft office is to work with others in my organization (who use VB extensively). Looks like Parallels with vista for me in the future and iWork for most of my day-to-day stuff that doesn’t require cross-platforming…
I started writing applications for Word with version 2.0 of WinWord. I wrote one of the first books on wordBasic. I wrote some of the templates that shipped with Word 6.
I’ve been developing two major applications for Word since 1995 or so. ScriptWright and BookWright. They transform the Word interface into dedicated screenplay and book applications.
This is possible because Word’s fundamental design — moreso in earlier versions than in the most recent — rested upon the idea that NOTHING that could be done in the UI could not be addressed in the underlying programming language.
From the developer’s point of view wordBasic and VBA were not additions to Word, they were the essence of word. Combined with Templates and Add-on capability, they allowed a programmer to add features, change features — to completely change the interface.
The removal of VBA from WordMac is a horrible decision and should be reversed.
It matters not at all that it doesn’t communicate with other apple work flows. Neither did the original word basic without major surgery — like DDE and API addressing.
The point of vba is to allow customization of Word as much as it is to aid in interoperability.
The genius of the early releases of Word, and no small part of its victory of other word processors in the market place, was precisely this open architecture. It is frightening to see the MacBU give up on trying to match the Windows version. Just as it is frightening every time the Windows unit adds another feature that cannot be completely controlled and addressed from VBA.
Both units are infatuated with themselves and are not paying due homage to what made this product succeed.
I have tried, with each release of a Word for the Mac, to port my applications from Windows. In previous iterations (Word 6 and Word 98 under OS/9) I gave up (after no small investment of time and money). They just wouldn’t work cleaning.
I bought a new OS/X machine a little over a year ago. To my delete the conversion seemed to be progressing. And I recently released the first of my two major applications BookWright. Then I discovered that this is a one cycle success. Why bother with porting the screenplay application? My users will have to stay with Word2004 if they wish to continue with my product.
The suggestion that I can achieve the same results with RealBasic or Apple Script — well that is simply wrong. Those are layers outside of Word. My applications word from within and must do so. Similarly, the Windows unit is suggesting to developers to move to NET of VSTO. It just proves how little this generation of programmers at MS understand about the internals of Office.
–Guy
I think the fundamental problem is that your basic premises are skewed. You say, “Mac Office has two primary driving requirements:
1. it must be as Mac-like as possible, use Mac features, and take advantage of the Mac operating system, and
2. it must be as compatible with Win Office as possible, and share as many features and commonalities as it can.”
In fact, the only requirement that counts AT ALL is #2. Macs have always had excellent word processors and spreadsheets and presentation packages — programs that many Mac users prefer over MS-Office. The ONLY reason that MS-Office has had an indispensable position on the Mac is because of its cross-platform compatibility — a compatibility, by the way, that is actually rather poor compared to what has been achieved by OpenOffice on all of the platforms that it supports.
Make the Mac product look and operate EXACTLY like the MS-Windows product and it will have better compatibility. More companies will be willing to use it because it will cause less trouble for their MS-Windows users. The fact that it won’t be a “Mac app” is actually irrelevant. No one buys MS-Office because it’s such a great Mac app; they buy it because they need to be able to exchange files (and macros) with MS-Windows users.
As an aside, if all of Microsoft followed clean programming practices in the first place, your code would be more portable, *and* more secure, as well as easier to update.
I completely agree that the first priority of Mac Word should have always been and should now be feature by feature compatibility with the Windows version of Word.
No matter how awkward the transition, Microsoft has the resources and the brains to make VBA work in MacWord — and has the ability to release feature mapped versions of the program on both platforms.
To contend otherwise is completely is, literally, incredible.
My suggestion to both the MacBU and the WinWord BU is that they hire some new guy to data mine through the old CompuServe MSAPPS forum — surely someone has kept a record of those early days when the DevTeam actually spoke with power users rather than focus groups — and try to recapture, re-imagine, the astounding beauty and functionality in the original WinWord design. That’s why WordPerfect was crushed. Why AmiPro and WordStar 2000 never had a chance. Word for Windows dominated PRECISELY because of the elegance of it’s design, because it was customizable, because you could make it do anything you wanted.
You guys have forgotten why you’re making this thing.
Hi,
I want to know if it is possible to run the windows version of MS Office on an intel based apple mac.
This is because i’m contemplating purchasing a macbook, but already have office from my other windows notebook and would prefer using that than purchasing the office which is for macs.
Thanks in advance.
ciao
Sisco
In order to run Windows Office on a macBook, you need 1) to have a copy of Windows you can install on the machine 2) run Boot Camp or purchase Parallels.
Oy,
Every time I’m about to give Microsoft a second chance, they go and pull some stunt like this. From the sounds of this article it would seem that Microsoft is doing exactly as it appears- repeatedly reskinning the same code with no real reason to upgrade and now for me no reason to purchase at all. Every couple of years folks are charged $500 per user, just for the right to make word documents, a spreadsheets or two and some slide projections?
Mix up the format and bam… it must be a better file, but as this article clearly shows, its all built on dated technology. Well, this announcement synched it for me. I was going to give Mac Office a try for development since I can code in VB, but I’ll just pitch the VB altogether. So, in a way this works out for everyone. I have less to worry about supporting and Microsoft has less to worry about selling.
This is a real pain in the butt for me. I have developed a number of excel sheets and programs using VBA extensively on my Mac, for final use on XP systems. I dope someone will produce a converter of some sort as I will be stuffed by this decision.
The only other option I can see is installing XP version of Office to run under parallels, but I really dont want to have to buy Parallels, Windows and Office for windows.
Ok The decision is made, but perhaps a more suitable decision would have been for the Windows Office to be written with cross platform in mind. Maybe this could happen in the future, so the same version of office could run in Windows, Mac and Linux
I’m just a home-using lurker breaking in on a conversation I barely understand, but it’s very educational. As a home user with pretty simple needs, I begin to see why MS software is so hugely bloated and hugely expensive (and therefore so hugely popular on the Gnutella circuit). MS creates this kind of software to satisfy the requirements of its large corporate customers, and then turns around and markets it as consumerware as well, expecting average consumers to pay for the development of features they do not want, need, or understand. So I guess when I pay the huge price for MS Office, I am in effect being expected to help subsidize Corporate America. No thanks. From now on it’s Open Office or iWorks for me!
Oh please!! Apple can get PowerPC code to run seamlessly on Intel chips and yet Microsoft in this blog says “it has turned out to be quite difficult” to find someone to port VB to the Mac!! What a flippin’ management joke. If I worked at Microsoft I would be embarrased for the MacBU management to play victim of this. Clearly, the management team doesn’t bonus the outstanding engineers well because I GUARANTEE you there is someone there that could get the job done.
Good decision which signs the MacBU cohrence with its target platform.
To appease VB writers they have to know their switch will be easer as ever so great is now AppleScript, stable, finely documented, enough speed, very well integrated with Xcode / Interface Builder, and so on.
Thanks for explanation. Continue to produice this so mac style office suite as Win users continue to be jealous of
It does not remove anynothing to other suites than it’s needed to salute, free or not, mac, win or xplate based.
not that i understand any/all the technicalities but…
it does indicate to me that this creates a serious wedge petween the 2 platforms. mac’s next big growth market must be the mainstream business environment.
the only way for mac to make inroads there is to have FULL compatibility.
by not allowing this in the business tools companies use most, ms is protecting its windows turf. this is not a resource-allocation decision, this is a business strategy. it is very bad news for mac.
it emphasizes mac’s need to be ms independant and to continue to develop its own software.
i hope this decision comes back to haunt ms in a big way.
Despite your explanation, it is not just apparent that MS is preventing the Mac market from achieving a foothold in the enterprise market – it’s a REALITY. Let’s face the facts – the MacBU is a decent profit center for Microsoft. Mac Office easily is one of the best-selling apps for the Mac platform. The Mac community has stood behind it because of its outstanding cross-platform compatibility. Now you are ripping out one of the most important elements of that compatibility.
Regardless of the pain and suffering it will inflict on developers, MS has ripped the rug out from under us and potentially has forced most of us Mac users in the business community to run Windows on our Intel Macs and run Windows Office. Sorry, your explanation may be convincing to some, but not to all of us. Let’s face it – if MS really wanted to keep VBA functionality in Mac Office they would devote the resources to doing so. As in Jeff’s post above, MS INDEED is protecting its Windows turf. The MacBU blew it here. You guys MUST reconsider – otherwise most of us will be stuck in the Rosetta world of Office 2004 for a long time to come.
A pathetic excuse for a company that clearly wants Windows domination. Sorry but that’s the message Microsoft sends “the rest of us”.
You know, this whole writeup is suspect to me – As the Intel lineup progresses, the performance hit from running Office 2004 with Rosetta will become increasingly mitigated. You could solve the whole damn problem if M$ released a patch for Office 2004 that makes it compatible with the Office 2007 file format, but of course, where’s the profit in that?
Thanks for the info – but I am afraid that due to the heavy use of Office at my work (where we use Windows 2000), I probably won’t be upgrading to the next Mac Office. I simply by need will be forced to continue using Office 2004 or find an alternative. It is disappointing that MBU did not think of this as a high enough priority. I honestly believe that sales of the next Mac Office will be lower than the current one.
With the rise in home purchases (albeit a small one) of Macs, the need for cross-platform issues to be as transparent as possible will be even greater. I know this will be a huge issue for me – sorry to see MBU making this (bad) decision.
Pingback: VBA for Macintosh goes away — myhotblog.com Archive
Pingback: links for 2007-04-26 « it’s hard to be a bot on #fsav_linux
I fought with Microsoft to include Office for Mac in my MSDN Universal (which wasn’t all that ‘universal’ after all) subscription because I had clients who used Macs AND PCs interchangibly. If I were to truly support the VBA code I delivered, a Mac environment would have to be there, and the promotional material for MSDN Universal proclaimed that it supplied ALL platforms that VBA was on. In the end, Microsoft shipped me a commercial box of the gold-level of Office 98 (if I recall correctly the version number) for Mac, perhaps just to shut me up. The fact that they did not natively include Office for Mac in that $3000+ product (MSDN Universal) shows to me that Microsoft was not committed enough to really being serious about building a VBA developer community for the Mac.
This post is amazing, by the way. Here we have a manager / leader / developer at Microsoft, a software DEVELOPMENT company, complaining how hard it is to build software! Duh. What should Apple have done for you, give you a big green button and volià here is your fully-functional and backwards-compatible VBA? Building something like VBA is not a trivial task at the best of times. Development is FAR more complex than it was when big Billy G. hacked against Microsoft Basic in the 1970s. To be retreating from the challenge, even though the bar is higher than yesterday, says to me that you are not up to the challenge, and perhaps you are not the right person / team / company to lead the way to tomorrow. To quit because something is hard is a cowardly response, and a way to certain defeat. You allies (all those developers you’ve heard from) in the trenches have been let down by your abandonment of the battlefield. Such a move, no matter how ‘justified’ is a choice that will have grave consequences for your business for years to come. You’ve given up the fight and abandoned ground you’ve invested years and millions of dollars in winning.
Time for a new general.
I’m coming late to this discussion, but the simple bottom line for me is that, particularly over the last 2-3 years, most of the documents I receive (Word or Excel, and maybe even PowerPoint), have macros in them.
Dropping support for VB will likely make these documents unreadable in newer versions of Office. So there’ll be no incentive for me to upgrade to Mac office, leaving me with two choices Open Office/Neo Office, or running a later version of Windows Office under some sort of virtualization software.
Neither alternative bodes well for the MacBU.
The other point I’ll make is, despite the -superior- job the MacBU does ‘mac-ifying’ MS Office, I’m still really upset at the chronic bugs I run into that never get fixed. #1 on that list is double-clicking a MS Word document, selecting Print, causing MS Word to immediately crash.
dave
From what I understand, you guys had three options:
- dropping VBA for Mac in the next Office version, even if this hurts a minority, but a loud minority of users – this is what you chose ;
- porting the existing code base, which is a technically hard thing to do, because an enormous legacy code which contains deep dependencies into obsolete assembler, PPC and windows code. You expect that porting to be outrageously expensive, and worse, to take two full years to complete, which is why you won’t do it.
- just rewrite the hole damn thing in a modern high level .Net language, get your-selfs or buy a nice modularized editor and build the interpreter in three months, and spend 6 months in testing as to pick compatibility errors.
I mean, two years to port an existing application, this just sounds like a communist apparatchik junta deciding over the fate of the old town bridge built in the 19th century, while blaming it’s architects for not forecasting 21st century’s trailers over it. This and that blog over how to build a desktop side bar in a three years period are just throwing lights over what has become a giant buraucracy, shame on you.
RIP Office Mac.
I’ll buy an extra couple copies of Office 2004 to tide over my organization for any potential needs in the next couple years while I investigate migration alternatives — although such alternatives are unlikely to involve Windows or MS Office, aside from maybe one document recovery and conversion machine (as it slowly become impractical to continue using 2004). Without cross-platform scripting compatibility there’s little reason for me to stick with Office.
Office 2004: the last useful version of Office for Mac. Kind of a shame to throw away an otherwise reasonably good product line, and it sure throws a spanner in the works for me, but I guess the world has to move on. Oh well. RIP.
Perhaps Microsoft’s new Dynamic Language Runtime (DLR) and VB10 (which are slated to be cross-platform) will come to the rescue but not too soon since these technologies may not see the light of day until maybe 2008/9.
See this post from Paul Vick: http://www.panopticoncentral.net/archive/2007/05/01/20383.aspx.
I hope that the MacBU will check these out!
—
Taiwo
Late to discussion, but others have hinted at making VB for Office follow similar model as GCC — a frontend editor/compiler which translates into a bytecode or intermediate language capable of interpreter execution or compilation through Xcode/GCC [maybe Java, bringing a host of new objects which could be embedded in documents?]
Scanning the post above, seems VBA is struggling with legacy approach (probably dating to Win3? and slow cpu’s). Amazing such a valued tool could create a major headache for the big “M” ?
To compare stories, years ago when enterprise computing introduced 4GL’s for business queries, tons of reports and queries were written; the major issue again became compatibility and converting those reports and queries to the latest technology–SQL, Access or Excel spreadsheets.
Does this merry-go-round ever stop?
Pingback: My Software Blogs » Blog Archive » Blogged by Joel Spolsky - VBA for Macintosh goes away
Seems people are under the impression Microsoft is somehow obligated to do a “proper” full version of Office.
Thats just not true. They almost certainly could make more money using the MacBU developers for other jobs, they just keep it going for goodwill and to be seen as playing nicely with competitors.
Plenty of platforms have seen major applications just dropped because they are too expensive. For example Lotus Notes only supports Windows for a client now despite thousands of businesses using it on other platforms. It could EASILY happen to Mac Office.
Actually, there is no need to build the equivalent of a compiler into Office for Mac in order to deal with VBA macros. Nor is there any need to implement a translator.
Solution:
1. Remove the PPC byte-code compiler/linker completely and discard
2. Create a simple byte-code to C translator, which emits each macro as a C function. Don’t worry about generating efficient C, the compiler (step 3) will take care of that.
3. Compile the macro(s) using your favorite (external) C compiler.
e.g. system(“gcc -O3 …”);
4. Dynamically link the compiled macro(s) to the Office executable.
e.g. dlopen(…);
5. Find macro function entry points and save in a suitable data structure.
6. Call the compiled VBA macro functions as necessary.
7. If feeling adventurous, embed the compiled object(s) in the Office document that contains the macros so that compilation is a one-time effort.
How hard is this? Worried about the cost of calling a compiler? It’s faster than you might think, and better than losing compatibility and all those paying customers. And if you need a hand – I’ve done this before.
Was there any follow up to this. I have no idea what your saying here but it seems if you found a possible solution that someone should say whether this is feasible or not?
Yeah.. It would be interesting to see if there was a follow up to this. I bet not.
This does sound like a really feasible solution indeed.
what about LLVM anybody at MacBU?? or use an OSA component, with VBA as its language of course.
Pingback: MacMacken » AppleScript statt Visual Basic for Applications :(
Pingback: Python the new VBA ? « Gobán Saor
Pingback: Michael Tsai - Blog - Saying Hello (Again) to Visual Basic
It’s a shame that there are still such big differences between Office for Mac an d Windows. I work in the banking sector, and would love to see Macs being more frequent! Currenlty, to run a Mac while working in banking you would need a spare Windows machine as a backup for unknown problems.
Apple can get PowerPC code to run seamlessly on Intel chips
You’re joking right? You don’t know anything about your only real competitor Open Office? If that’s true then you’re incompetent. If it is not then you’re a liar.
You’re definitely lying about it ‘not supporting the newer xml formats’. It already supports the only ISO standard XML format – ODF.
Seems people are under the impression Microsoft is somehow obligated to do a “proper” full version of Office.
Thats just not true. They almost certainly could make more money using the MacBU developers for other jobs, they just keep it going for goodwill and to be seen as playing nicely with competitors.
Plenty of platforms have seen major applications just dropped because they are too expensive. For example Lotus Notes only supports Windows for a client now despite thousands of businesses using it on other platforms. It could EASILY happen to Mac Office.
Why couldn’t you make a Visual Basic to Applescript converter. Mac Office could open a document with embeded visual basic macros, convert the script to applescript, run it through the mac interface that they decided to implement instead, and you’d see little loss of functionality. For compatibility, the converter would work in reverse as well. Applescript macros written in Mac Office could be saved to Visual Basic macro format so that windows office could open it and still run the macros. Wouldn’t that be a far easier implementation than spending 2 years straight completely rewriting it? As long as the macros still work and are compatible, I doubt anyone would care that it’s not running on VBA.
Pingback: Office 2008 starts very slow - Page 4 | keyongtech