Virtual PC and Visual Basic

Scene: A fly-over view of Microsoft's campus focuses in on the building that houses Mac BU. The camera "flight" enters one of the offices through a window. During the fly-over, a voice-over says:

  • New 3.0 GHz Mac Pro: $3,599.00
  • Two 23" Apple Cinema HD Displays: $1998.00
  • Office space: $350.00/mo
  • Competent developer...

You get the picture. For years, one of our program managers has been coming into my office with feature questions that invariably begin with, "Is it possible to...?" Well, of course it's possible. Anything's possible if you give me enough time.

So, earlier this week, we announced that we're not going to ship a Universal version of Virtual PC and that we're going to discontinue support for Visual Basic for Applications. The latter is particularly painful for a number of our customers, and people are quite understandably livid about it.

While Erik Schwiebert has posted a sound explanation of the technical hurdles involved, there remains the more general question of finding the resources capable of doing the work required to overcome those hurdles. Many people who are not at all familiar with the exigencies of software development look at Microsoft's balance sheet, and the maxim that anything's possible in this industry, and wonder whether or not we're pulling their legs. They don't understand that the constraining resource isn't money. It's people.

There are two pieces in the people puzzle. The first is head count, and, for various reasons, Mac BU has always operated with open head count. "Open head count," means having a budgeted slot to hire someone, but not having an actual employee in that budgeted slot. Due to the turn-over of people who move on to new challenges, and the difficulty of finding candidates who we believe won't write something worthy of being posted to The Daily WTF, despite the steady stream we keep interviewing, I don't see this condition changing in the near future.

The fact that we've always had open head count points out a subtle aspect of the budgeting issue. Picture yourself being Roz Ho's boss. She comes to you asking for an increased budget for more head count. You look at the existing budget, and see that there are open head count. Your question is likely to be, "Why are you asking for more head count when you haven't filled the head count you already have?" The point: the people resource issue isn't a budgeting problem.

The second part of the people issue is a bit more difficult to understand when you haven't spent a great deal of time trying to ship software in the real world, but there is a point where adding new people to a project results in diminishing returns. Fred Brooks refers to this as the Mythical Man Month. If you ask me whether Mac BU is still on the increasing side of the curve or if we've come close to the diminishing side, I'd honestly have to say that I really don't know. This is one of those cases where you don't really know you've hit the point of diminishing returns until you get there, and, even then, recognizing that that you have is exceedingly difficult. There are a number of variables that affect the time it takes to complete a software project, and it's very difficult to account for them all.

However, Schwieb's estimate of two or more years to rework VB/VBA isn't far off the mark, and it assumes that we put every resource onto that project that we can possibly put on it. That estimate also takes into account the issue of dependencies. This part of the Mythical Man Month isn't all that well discussed in the Wikipedia article linked above, but it's one of the more important problems we face. The number of people you can effectively put on a project is determined by the number of discrete tasks into which the project can be broken down and by the extent to which those discrete tasks depend on the completion of other tasks.

Consider the VBA execution engine that Schwieb mentioned. One might be tempted to take each opcode, and turn that into a discrete task to be worked on by an individual developer. Unfortunately, that kind of approach will lead to less coherence in the overall project. Are there any common elements to certain subsets of the full set of opcodes? If there are, and we have one developer per opcode, then there's a high probability we'll have a large number of subtly different implementations of these common elements. The more discrete tasks into which you break up a project, the greater the logistical difficulty of integrating each of those discrete tasks into a coherent whole.

Now, I've read a number of suggestions that people have made: take a Ruby on Rails approach, figure out a way to use PowerPC/CFM VBA running under Rosetta, and a few others I can't recall off the top of my head. There are ideas we'd explored that I haven't seen anyone suggest. I can't think of any one of them that would not have involved more work than working with the design parameters of the current VBA implementation--not the least of which is the fact that all of the applications implement their object models using the OLE Automation, dual-dispatch/type library approach. One has to be very careful with such ideas, because there are a number of hidden gotcha's that are very difficult to accurately assess.

So, could we have done something about VB/VBA? Certainly, if we'd had enough time. Do we make those users who really don't care about VB/VBA wait several years before we ship a Universal Binary version of Mac Office? At some point, the tail starts to wag the dog.

But that does not mean we are unaware of the pain this will cause to a significant number of users. If you think we are not aware of that pain, consider this. David Weiss can give you a better number on this, but our testing methodology has always made extensive use of scripts for automated tests. Not just a couple of scripts, but thousands of scripts per Office application. At one point, all of those scripts were written in VB/VBA. In order to carry that testing effort forward into the era of Universal Binaries, every single one of those scripts had to be rewritten in AppleScript. I don't think it's even a remote exaggeration to say that our use of VB/VBA was at least a couple orders of magnitude greater than even our most automated customers. Do we know your pain? You bet we do.



Currently playing in iTunes: Feel So Bad by The Derek Trucks Band

Comments (66)
  1. RMansfield says:


    For what it’s worth, I appreciate yours and Schwiebert’s effort to explain the loss of VN and VPC. VB doesn’t affect me because I don’t use this feature, but I know it’s going to be a mess for a lot of people and some may not be able to keep their Macs at work. Maybe that’s where Bootcamp or Parallels could pick up the slack. I don’t know. I’ve used VPC since v. 2 when I first switched from Windows to the Mac in 1998. I don’t have to use it all that often, but I’m glad it’s there and it even runs decently on my 1.67 ghz PowerBook. I’m sure it will be a couple of years before I upgrade to an Intel Mac, so VPC will continue to run alive and well on my machine and I’m sure a number of others.

    I’m kinda suprised that there was no preview of the next version of Mac Office at WWDC. I would have thought that a preview of the next version would have been a good strategy to offset some of the negative reaction against the loss of VB and VPC. And it would counter all those who used the cancellation of these products to say that MS was leaving the Mac. I have no doubt that the MacBU is made up of people who get the Mac and are committed to the Mac, but we DO sometimes feel like neglected stepchildren. So what are the chances of us getting to see a preview of Office 12 anytime soon?

  2. Rick Schaut says:


    I’m not sure a preview version of Office would be appropriate at WWDC, but, then, I’m just a dev.  I can say that we have too much visual stuff that’s not even ready for pseudo-prime time.  I certainly wouldn’t feel comfortable previewing this now.  Having said that, I’m sure we’ll have something by Mac World in Janurary.  Whether or not there will be bits that people can actually play with by then, I don’t know.

    And, yes, I understand the neglected stepchild  feeling.  As I often say to some of our IT customers, if you think your IT manager is Windows centric, you should see mine.

  3. pherplexed says:


    I’ve enjoyed reading your insights on the macBU.  It’s a reassuring to hear information straight from the source.  But, the relationship between Apple and Microsoft continues to worry me.  

    It was announced last year that MS has agreed to develop for the Mac platform for at least the next 5 years.  My question would be that if Office 12 for Mac doesn’t arrive until early/mid 2007 (2 years into the agreement),  do you think we’ll see a dead stop in Office progression for the Mac as we have with Office 2004?  Unless a new agreement is established for another 5 years, it would seem to me that MS would just let it die.  

    Which leads to my last question: if Office for the Mac ever did go away, what is the likliehood that the iWork suite would become interoperable with Office for Windows?  

  4. klye says:

    I understand where you’re coming from… it all makes sense.

    From a user perspective I see this: The Mac BU has always been a MS afterthought, a hedge against anti-trust allegations and a way to keep Office in a dominant position as a document creation tool across desktops.  That the BU has managed to make great software (Word 5.1, Word 2004, and Entourage)  is a testament to the type of engineers attracted to the division but the rest of MS basically doesn’t care… and we all know the best BU developers eventually get picked off for higher priority projects.

    It was obvious to everyone that Virtual PC for the Mac would eventually die when MS bought it. While VPC was part of connectix it was upgraded regularly, regularly saw increases in speed and performance, and was an exciting product. In the hands of MS it was upgraded occasionally, for compatibility and that’s about it.  My guess is that if it were the product still in Connectix’ hands it would still be a vital evolving and competitive program. I imagine for example it might compete with Parallels but do it one better by using Boot Camp Hard drives seamlessly, offer clean user switching and the option of dedicated booting or side by side emulation etc. But from the MS perspective, VPC is now one less bother. The engineers who created the guts of VPC for Mac have already long gone off to other projects… "thank god let’s put this baby to bed… seems to be the sentiment."

    With Visual Basic I imagine the calculation is simple: if the user needs visual basic, force him to run it under windows. He’s already got windows on the machine and if he doesn’t he should get it… "Why bother."

    The only software I expect to see out of the BU for the next few years is a Universal version of office and an Office 2007 file importer… Forget about any significant enhancements to any of the programs in the suite. This will simply be a compatibility update that allow users to read and write Office files which is is the MS bottom line… And if Apple develops a built in Office suite that allows seamless read/write of office files then you can kiss the Mac BU bye bye… It will no longer be needed and everyone will be reabsorbed into the borg.

  5. Rick Schaut says:


    The 5-year agreement was all eye candy.  John Welch does a good job deconstructing the whole argument about it here:

    Note that, between the two five year agreements, we continued to produce quite a number of products, and that had nothing to do with any antitrust issues.  It’s a good business.  Last fiscal year, we did record volume both in revenue and in units.  Don’t expect Mac BU to go away any time soon.


    Virtual PC probably deserves a post of its own, but I should point out that our Group Program Manager came from Connectix.  If we were simply looking for an excuse to mothball Virtual PC, do you think he’d idly sit by and let that happen?

    I’ve noted your expectations.  Can I get a commitment from you to come back here and tell me how well we’ve exceeded those expectations when Office 12 ships? 🙂

  6. Nick says:

    I’m not one of those crazy Linux junkies, but isn’t an obvious solution to look to the open source community for help? I realize there are tehcnical hurdles and possibly IP issues with just releasing the code you have into the wild, but couldn’t you at least start up a project and maybe lend some code to it, even on occassion? It’s one thing for us (customers) to complain about the speed of MS doing something, but if you’re just going to drop support for something entirely why not turn at least part of it over to the community? While you may not be able to find people who are suitable for employment at Microsoft, there are still lots of capable programmers out there who could contribute to a project like that.

  7. Rick Schaut says:


    We’ve explored, and continue to explore, a number of options.  Since that’s in Schwieb’s bailiwick, I don’t know the details, but I’m willing to let Schwieb and our program management team do their job.

  8. some more details about our latest announcements

  9. eponymous coward says:

    OK, this is kind of a troll, but it’s something you might think about:

    Name the last time Apple removed a feature this big from their cross-platform app (QuickTime).

    Or Adobe (pick one).

    That’s not to say this wasn’t the right decision- but you might think long and hard about how you came to the point where you had to make Sophie’s Choice, and why you don’t want to be in the position of giving the finger to users.

    The MBU talks a good game, and I don’t doubt it has good intentions- but the road to hell is paved with them, and fragile cross platform applications, as the people who did FrontPage and Mac Outlook could tell you- and Microsoft has a rather large history of dropping Mac apps. On top of VPC and VBA and the two I mentioned, there’s IE, MSN, Outlook Express, Encarta, FoxPro…

    For a company that loves the Mac users like the MacBU does, you sure do kill off a lot of software for them. That diminishes credibility. The way to get it back is to make us go "wow". I sure hope you can do that in Mac Office 12, for your sake, because Apple isn’t just sitting around with Pages/Keynote/Mail/iCal/Address Book. Once whatever spreadhseet app they have in the basement of One Inifite Loop sees the light of day at a Macworld SF near you, they match up with Office pretty well, now that VBA is toast- and it doesn’t take THEM three years to rev the app a major version.

  10. I think that if there was, even a Q&D way to do a one time "convert VB to AppleScript" tool that could be run, that could help a lot.

    Making Word an AppleScript *recordable* application would help out with some of the pain too.

  11. Neema Agha says:

    IE – dumped

    Windows Media – dumped

    VPC – dumped

    VB/VBA – dumped

    Let’s see, you cripple the software, neglect it for years until "usage drops off" and people don’t upgrade and you justify killing the project.

    We’re not stupid. We see the future. So, when we start investing in other software, don’t be surprised. You’ve set a precedent for screwing us Mac users.

  12. Christopher Anderton says:

    I´ve seen a preview at the new Office at a MS meeting in Sweden. The UI looks really good. Task based GUI, tabs, and a very very Apple like GUI. Espacially the prefpanel. And the new features (and apps) is really exciting for business user.

  13. has says:

    "figure out a way to use PowerPC/CFM VBA running under Rosetta"

    Simple enough in theory (famous last words, of course:). You decouple the VB-related code from the rest of Office, then move it into a PPC-only agent that can run under Rosetta while Office proper runs natively. In practice though… well, it depends on how easy it is to separate everything out; even the best architecture gets knotty with age. Plus VBA’s on its way out anyway, so maybe jumping sooner is better than dying later.

    "There are ideas we’d explored that I haven’t seen anyone suggest."

    Ooh, I enjoy a good guessing game… 🙂

    – OK, given the timescale, I imagine porting the CLR and whatever else Office/Win will eventually switch to is a total non-starter, at least for the next two or three years. So scratch that one.

    – There’s also the move-VB-stuff-into-its-own-process idea, but that’s only an ‘easy’ option if the internal guts are clean and well laid out to begin with, and not all tangled and laden with voodoo optimisations and age.

    – The next idea would be looking at RealBasic to see if it could provide a viable cross-platform engine with a decent level of VB compatibility. I think you must’ve done that by now – it’s too obvious not to think of it – and it came up dry for one reason or another.

    – You may also have considered embedding a JavaScript interpreter for cross-platform scripting, like the cool kids at Adobe do.

    – A less obvious possibility would be if the VB and Apple event APIs are reasonably similar in object hierarchy and commands. If they are, you could take an existing cross-platform scripting language that can talk to both and whip up some glue libraries that present a common API to scripts on both platforms. Folk can then write scripts against this API, which takes care of the cross-platform issue, at least from the technical standpoint (political/cultural differences are a different issue, of course). Python’d be the most likely bet here since it’s mature, well supported on both platforms (MacPython, IronPython/Win32All), not too cognitively dissimilar to VB, and already has the makings of a VB-to-Python converter (vb2Py) to help users to port/run existing VB scripts. (The OSS community could even tackle this one themselves if they wanted.)

    – Finally, you could dress in black polo-necks, infiltrate Cupertino and replace OS X with a similarly skinned Windows XP, then hope nobody notices the difference. 🙂

    p.s. Sympathies on the passing of VPC (ah, fond memories), but it sounds like the right decision given the market situation.

  14. Rick Schaut says:

    Eponymous, why limit the question to cross-platform apps?  So we can arbitrilly exclude things like OpenDoc, QuickDraw GX and the ability to run classic apps under Mac OS X?  The latter is just as big as dropping VBA, and is indistinguishable (we’re replacing VBA with improved support for AppleScript–support that is already pretty solid in Office 2004).

    John, we’re working on ways to do both, but I can’t make any promises.

    Neema, of course you’re not stupid.  However, being intelligent carries with it an active imagination.  I just don’t quite follow the logic that has us purposefully leaving real money on the table just to spite Apple.  Is there some reason you have to think that we’re that stupid?

    Has, see, now, that’s the kind of active imagination I like to see :-).  Schwieb left out some details in his technical discussion, the most notable being that the applications all implement their object models as OLE Automation objects.  There are third-party modules and applications that use these OLE Automation interfaces (e.g. RealBasic).  If we pick a solution that forces us to reimplement the application object models in some other way, then we break those bits as well.

    Really folks, if we could have figured out a way to do this and not make everyone wait at least another two years for the next release of Mac Office, we would have done it.

  15. Rick Schaut says:

    Eponymous, why limit the question to cross-platform apps?  So we can arbitrilly exclude things like OpenDoc, QuickDraw GX and the ability to run classic apps under Mac OS X?  The latter is just as big as dropping VBA, and is indistinguishable (we’re replacing VBA with improved support for AppleScript–support that is already pretty solid in Office 2004).

    John, we’re working on ways to do both, but I can’t make any promises.

    Neema, of course you’re not stupid.  However, being intelligent carries with it an active imagination.  I just don’t quite follow the logic that has us purposefully leaving real money on the table just to spite Apple.  Is there some reason you have to think that we’re that stupid?

    Has, see, now, that’s the kind of active imagination I like to see :-).  Schwieb left out some details in his technical discussion, the most notable being that the applications all implement their object models as OLE Automation objects.  There are third-party modules and applications that use these OLE Automation interfaces (e.g. RealBasic).  If we pick a solution that forces us to reimplement the application object models in some other way, then we break those bits as well.

    Really folks, if we could have figured out a way to do this and not make everyone wait at least another two years for the next release of Mac Office, we would have done it.

  16. eponymous coward says:

    I think you missed my larger point, Rick (though you could toss in Pagemaker/Framemaker into that, I guess). Apple taketh away, but they also giveth. The universe of software Apple provides to delight their customers is unquestionably bigger than it was 5 years ago. Can you say that about the MBU, honestly?

    The MBU has taken away a LOT of software the past few years: IE, OE, VPC, MSN. That’s not counting the software that has been killed outside the MBU: Mac Outlook (Entourage STILL does not completely replace it as an Exchange client, though it’s very close, and does some things it never did…5 years later), Frontpage, Encarta, Windows Media.

    You may protest that all those decisions were made for valid reasons, not as "Hey, guys, let’s kill off the Mac because we hate Steve Jobs". I don’t doubt that, not for an instant. But step back and look at the bigger picture, here. The largest ISV for Apple has, over the past 10 years, regularly killed multiple software products for the Mac. That, in and of itself, is a statement- the company, as such, isn’t particularly committed to cross-platform products except in a tiny band of their software, and a good chunk of that band has recurring technical problems that limit their ability to have truly cross-platform products:

    – MSN Messenger? Still not doing video and audio.

    – VBA? Toast.

    – VPC? Sorry, only on Windows going forward.

    – Windows Media? Sorry, need to have a 3rd party doing it.

    – Windows Presentation Foundation? Well, we have the "reach client" version, WPF/E…

    – Remember this <A HREF="">golden oldie</A>? I’m somehow doubting IRM is going to happen anytime soon on the Mac, either.

    Look, as I said: I don’t doubt the technical reasons behind what you’re doing are utterly valid. In <B>isolation</B>, they are prefectly understandable. As a collective whole, though, I see a company where the Mac users are regularly pawned off as rounding errors compared to the revenue Windows users represents, a group (the MBU) where you’re slowly but surely surrendering territory on the field, bit by bit, as a result of the fact that 200 people are being asked to duplicate the work of thousands.

    But hey, you’re on the inside, I’m on the outside (for now). Prove me wrong. Surprise and thrill me in Office 12. Delight me with something Steve would be happy to show off in an iApp at MWSF, or goes to his iApp people and says "hey, why can’t we do that?". I’m sure you can do it- in fact, I seriously hope and wish you can do it, even while you’ve got your heads down making sure Office 12’s file format works both places (file formats, by the way? Not sexy. It’s like the plumbing on your house- you have to have it, but nobody’s going to show it off compared to your big-screen TV).

  17. Rick Schaut says:

    Eponymous, I thought I’d answered the larger question earlier when I pointed out that this past fiscal year was Mac BU’s best year ever.  I think that means we’re doing something right.  Do we have to make the universe bigger in order to be considered a success?

    I’m always leary of "prove me wrong" challenges, because the challenge carries hidden priorities that don’t necessarily map to my customer base.  I don’t care about getting Steve Jobs to say "Wow!," because Steve is several levels removed from the real world problems my customers face.  What I want is for current and potential Office users to say, "Wow!" by upgrading to the new release.  I want those customers to look at the product and say, "That’s going to make my life easier."  That is the only goal I am _ever_ going to have, so please don’t ask me to take on a different one.

  18. has says:

    "There are third-party modules and applications that use these OLE Automation interfaces (e.g. RealBasic)."

    The Apple event interface too? I’m guessing it’s just a thinnish wrapper around the Automation interface – from what very little I’ve read about VB/COM (I’m an Apple events sort myself:) it seems to have that look and feel. It’s certainly not a normal Apple Event Object Model.

    Though y’know, black polo-necks outside Cupertino at dawn might just work too, as long as you get in quick while they’re all away at WWDC. 😉

  19. eponymous coward says:

    There are lots of ways you can make more revenue from year to year- like selling VPC at retail. Which you aren’t going to be doing for very much longer, are you, seeing as Apple doesn’t ship PowerPC machines any more?

    That being said, OK, fine, you’re making money hand over fist while killing products. So… when do we see new apps that aren’t Windows ports with lessened functionality, if the MBU is loaded with cash? When do we quit hearing "Sorry, we won’t do this, ever" being told to users, and start hearing "We’ve got something exciting for you"? Or is the MBU’s job these days simply as a porting house to give a Mac shine and polish to Windows apps? Last time I saw something different from the MBU was Entourage- 6 years ago (and you could argue Entourage as a replacement for Outlook in the Office box). Everything since then has been stuff like MSN Messenger (sorry, no video/audio) or RDP (sorry, no multiple instances without a hack). That’s a lot of time in Internet years. Adobe does it, Apple does it, and they presumably don’t hire bums off the street to do their development, so the assertion "we can’t fill headcount" rings a bit hollow to me.

    Also, since I think you got confused about where I was going with my last set of comments: what makes you think _I_ am not part of your customer base, when I ask to be thrilled and delighted? The fact is if I didn’t use and buy Office, I wouldn’t care. Wouldn’t bother with the blogs.

    Pulling VBA out removes a reason to upgrade for me. So give me other ones. So far, I’ve heard you’re going to change the doc format, it’s going to be a Universal Binary, it’ll be more AppleScriptable, and VBA is toast. Not terribly compelling so far. I’m happy to wait and find out more, though. I’m just very tired of the same old "we’re killing _ (fill in blank) for this excellent technical reason" every. damn. year. It’s really old. In a universe where Apple cranks out annual upgrades to iWork or iLife, this pace you’re at, where all we get to find out for a couple of years are limitations, cancellations, and decisions on plumbing, is agonizing.

    Take it for what it’s worth- you certainly know your job, product and your customer base far better than I will. Maybe you’v already baked in all kinds of super-cool stuff. All I can say is, gosh, your coworkers on the other side of 520 have done some real innovation in Windows Office 12. Am I going to be just as impressed with what you did when it shows up 6/12/whenever months from now?

  20. Ken Liu says:


    Thank you for your post.  The explanation given by Erik is very convincing in setting out the technical difficulties of a universal version.  I guess Apple’s claims for the ease of using Xcode really doesn’t take into account projects with significant legacy code and assembler portions.  That’s life.

    By the way, do you enjoy using Xcode?  Or do you still prefer Code Warrior?

    I am unhappy to see VB go from Mac Office.  I’ve relied on it to make Excel spreadsheets that work well on both Windows machines and my Mac, and I guess I’ll have to figure out some way around it now.  Maybe I’ll just hold onto my old PPC machine and Office 2004 for as long as I can and hope that work doesn’t upgrade to the next windows office version.

    I’m sure you’ve done the necessary research and this decision makes sense, but I can’t help but wonder if Excel users really had their feedback taken into account.  Many of us use Mac Office at home in order to be compatible with Win Office at work, and Excel macros are just indispensable to any advanced Excel user.  

    Is there a chance that VB support will be brought back in the future?  Say, once the next version of Mac Office ships?  One can always dream…

  21. Rick Schaut says:

    Has, yes.  I blogged about VBA and AppleScript a while back here:  Sid and Nancy.  I trust you get Murph’s joke.

    Eponymous,  I know you’re a customer.  I don’t quite understand how you would think I could forget that.  Was my last paragraph in the original post not sufficient evidence that we have stood precisely in your shoes?

    In fact, go back and read the last two paragraphs.  Keeping VBA would have added at least two years to this release cycle.  Stand in my shoes, and tell me that you would honestly delay Office 12 for VBA.  Forget about flashy features.  Look at the new XML file formats alone, and tell me we wouldn’t be doing the vast majority of Mac Office users a disservice for that reason alone.

  22. One of the problems with developing software is that people don’t understand just how hard it is to develop software. I feel sorry for you guys at the MacBU with all the stick you get. Granted I did feel very similar at one point, the main turning point was a blog post one of you guys did showing all of the Mac you have there. A lot of people also seem to forget that Office was one of the first Mac applications (or at least, Word). I haven’t been developing long and many of my applications haven’t got to a stage where I’ve got a huge code base (cocoa helps a lot with that) but the amount of code you must have to work with must be staggering and this is what people need to realise. Imagine you were given a report of several million lines and you had to say change it from US english and grammar to British english and grammar and say you couldn’t just use a spell check. Now you might be able to understand a bit better the sort of problem develops of legacy apps face.

    Another point, directed to eponymous coward. Applications like Photoshop have a pretty similar code base on both Mac OS and Windows. I believe most of the differences are the UI code and the processor and OS optimisations. However, given that the features and release cycles are different, I would hazard a guess that the Mac and Windows Office code bases are completely different (would I be right in this Rick?) and so it’d harder to keep them in sync. If you are only having to write code once and then change a few bits depending on if it’s Mac or PC it makes it a lot easier to meet feature parity, otherwise you are always going to have differences. Having developed software for the Mac while trying to match another developer writing the Windows version I know how hard it can be and that’s just on a small scale with an app that was only about 4-5k lines of code

  23. Rick Schaut says:

    Ken, to tell you the truth, I’m still rather fond of CodeWarrior.  It has some editing and code browing features I miss.  XCode is incredibly slow opening even moderate files from the build results window, but the semi-opaque progress overlay sure looks nice.

    I strongly urge you to take a good look at AppleScript Studio.  There’s a bit of a learning curve for AppleScript, but it is every bit as powerful as VBA ever was.

    Martin, you are correct.  The Win and Mac Office code bases are separate.  We tried doing the concurrent development thing back in the Word 6.0/Office 4.2 time frame, and it just didn’t work for us.  A lot of that had to do with exigencies in the two markets.  And, yes, there are times when it’s a pain.  There are also times when it works in Mac BU’s favor.

  24. R. Kirk McPike says:

    It’s one thing to say "This would delay our product by two years" in regards to treating Mac customers right vis a vis VBA, and to not include it in Office 12 <i>so that 12 ships on time, while you can still finish the work and include it in Office 13</i> and doing what Microsoft is doing, and basically crippling all future versions of Mac Office.

    AppleScript won’t cut it.

    I have many Mac-using colleagues at the University I just left who rely on VBA macros in Excel to process grade reports, student worker pay schedules, etc. Without VBA, they won’t be able to do this anymore. And the accounting losers all use Windows PCs, so "AppleScript" is not an option. What’s going to happen to my Mac-using colleagues?

    How are you not leaving them out in the cold?

    How are they going to get by using a Mac when the Mac version of Office won’t support what they need to do anymore?

    They’ve been abandoned. You can say x, y or z, but you’ve still abandoned them.

  25. Jack says:

    I have been reading a lot about the VB/Office debacle over the past week, and although I find it a very interesting subject, to tell you the truth, I doesn’t affect me all that much, I’m quite happy with my Office V.x, it does everything I need, right now.

    My main desire is for information (anything really) about my favorite app, Messenger for Mac.

    I use this all the time (I mean ALL the time), and look at the win version with envy and bitterness…

    Is there nothing you can tell us, something to have faith, to wait for??

    I would really love that.


  26. Jonathan West MVP says:

    Of course, it is acceptable to drop features from time to time, but there is a need to ensure that doing so meets certain criteria if you aren’t going to suffer a backlash from customers.


    1. You provide advance notice of dropping the feature at least a version ahead of doing so, and

    2. You have an alternative solution that does the same thing in a different way and at least as well, and

    3. You run both the old and new versions in parallel for at least one release to give people a chance to manage an orderly handover, and

    4. You are convinced that by the time that you finally drop the old feature, only a very small proportion of your users are still using the old in preference to the new version.


    1. You are convinced that very few customers use the old feature.

    It seems that dropping VBA meets neither set of criteria, so you are going to have people extremely annoyed with you.

    Not so much developers, you are after all providing them with additional employment rewriting all the MacOffice VBA apps out there. No, the people who will be annoyed are those who will have the expense of paying developers to do this. You have essentially said "Rewriting VBA is too much trouble for us to bother with, so we are going to delegate that problem to our customers, so they will instead have to rewrite their VBA apps."

    Gee thanks!

    You challenged Eponymous to "Stand in my shoes, and tell me that you would honestly delay Office 12 for VBA.  Forget about flashy features.  Look at the new XML file formats alone, and tell me we wouldn’t be doing the vast majority of Mac Office users a disservice for that reason alone."

    I’ll take that challenge and answer "Yes". This is because adding file filters for the new XML file formats needn’t involve a new release – they are being added to the older versions of Office for Windows as a dounloadable component. You could do that for MacOffice (including versions older than 2004)to remain file format compatible while you get on with the job of doing the new release properly.

  27. Andre says:

    Question, will you ever release a preview beta of Office 12 for Mac before you hit GM?

    I think more eyes seeing the code would be a benefit to the team, reporting any kinks or flaws before GM.

    Kudos for the all the hardwork and dedication that you have put into transitioning to xCode. Hopefully xCode 3 on Leopard will give you the performance improvements you need. 🙂

  28. Rick Schaut says:

    Kirk, I think we know that we’re leaving some users out in the cold on this.  I don’t recall saying otherwise.  As for our plans for future versions, I’m not in a position to make any statements or promises.  All I can say is that we’ll take your feedback, and everyone else’s, and incorporate that into the decision-making process.

    Jack, to be perfectly honest, I’ve been so head-down in what’s on my plate that I really have no information about apps like Messenger or RDC.  Sorry.  There might be some information coming soon to the MacTopia web site.  I’ll post links if/when that information becomes available.

    Jonathan, I’d love to be able to do all four of the things you specified.  I just don’t see how it would have been possible, in these circumstances, to have fulfilled those criteria without the benefit of a flawless crystal ball.  We were half-way into Mac Office 12 when we found out about the switch to Intel processors.

    As for your answer to my challenge, think about how one might want to develop those converters.  You already have software components that read and write the old file formats.  Wouldn’t you take components, add the ability to read and write the new formats, and strip away the user interface code?  In other words, wouldn’t the smartest method begin by implementing the new file formats in the new versions of the Office apps?

  29. Paul Berkowitz says:

    The very same press release announcing the end of VPC and VBA also announced an imminent new version of Messenger:

    "Microsoft’s first native software for Intel Macs is planned to be Messenger 6.0, set for release later this year. It will allow people using the instant-messaging software on the Mac to talk with those running Yahoo Messenger–a feature that has been added to Windows Live Messenger, but is currently not an option for Microsoft’s Mac IM users. People will be able to share a message with buddies, as well as show which song they are listening to in iTunes."

    I don’t think there’s any other information about it, but there are sure to be more features.

  30. eponymous coward says:

    Rick, my point isn’t "You shouldn’t drop VBA".

    My point is "If you’re going to drop VBA, Office 12 for Mac should be pretty damn cool and sexy to make up for it. Having  file format compatibility with WinOffice, an EXISTING feature, does not cut it. Neither does being a native Mac app (aka Universal Binary)."

    Yes, I know keeping those "existing features" is an assload of work (oh, Lord, do I know this). It sucks to be you, that two of the checklist items for this release, that I know are consuming buttloads of time for this project, are the coding equivalent of redoing your plumbing and household wiring as part of a remodel- something nobody goes ‘oooh’ over the same way when you remodel your kitchen to add granite countertops or add on a deck.

    But then again, that’s what we’re paying your company the big bucks for, yeah? To go "oooooh, I gots to spend me some money to get that _".

    Basically…you see how Jensen’s been prostelytizing O12? We need some of that, please. ASAP.

  31. Jonathan West MVP says:


    Effectively, your answer means that Mac Office is abandoning the corporate market. Your corporate customers will not care that your job was difficult, they will only see that you dropped out of the job of ensuring that the next version of Office can run the programs that they ran in the last version. They will not upgrade. They will do one or more of the following:

    1. Continue to use older versions of MacOffice for as long as possible

    2. Consider moving across to Office for Windows

    3. Consider moving away from Microsoft altogether, lest they find themselves in the same position with regard to VBA in Office for Windows in the future.

    None of those will result in revenue to the MacBU.

    As for the file formats, if "You already have software components that read and write the old file formats" then why could they not be released at the same time as Office 2007 for Windows is released, so you maintain file format compatibility while you get on with VBA and the new UI features?

    Let me ask one further question. Is it your intention to re-introduce VBA in the version after?

    If the answeer is "yes", then since the intermediate version will gain you few sales and no corporate sales and lose you much reputation you might as well scrap it.

    If the answer is "no", then you can permanently kiss goodbye to MacOffice as a corporate application.

    I suspect that few individual users upgrade their copies of MacOffice, but only buy with a new computer. Therefore, a new version isn’t much of a benefit to you if you abandon the corporate market.

    Lots of different applications can read the same file formats – with Office moving to an open XML-based format, this will become een easier. There asre plenty of apps which provide broadly comparable features. It is VBA which ensures that your corporate customers are "locked in" to your products. You are throwing this advantage away.

  32. Jonathan West MVP says:

    "We were half-way into Mac Office 12 when we found out about the switch to Intel processors."

    Actually, this gives you an alternative approach. Forget about compiling to XCode for the moment. This isn’t a feature. If you must put out a new version on time, let it continue to compile to PPC and actually have all the features, including VBA. Thenfor the next version you do the necessary rewrite that will enable you to go native on the Intel platform.

  33. Rick Schaut says:

    Paul, thanks for the pointer.  As you all might well guess, I barely have enough time to read our own press releases :-).

    Eponymous, yeah.  We know we have to come up with more than just Universal Binaries and the new file formats.  We will be talking about some of the new stuff RSN.

    Jonathan, I don’t think we’re abandoning all of our corporate customers.  In fact, most corporate Mac users tend to be creative workers within a department like, say, advertising.  Even the "corporate" user isn’t a homogeneous market.

    And, yes, there are some people for whom this is a deal breaker.  Schwieb said so in his post, and I didn’t feel the need to repeat it in exactly the same way he did.  If "abandon" is a word you want to use for how those users are affected, then, I guess that’s your perogative.

    Lastly, I’m not sure how we can "forget about compiling [with] XCode."  Metrowerks is no more.  There’s an enormous risk that we’d run into a compiler bug that would require either a compiler fix or rewriting significant amounts of code (the ordering of bit fields within data structures in an example that readily comes to mind).  We have never shipped a version of Mac Office where we didn’t also take a compiler fix at some point during the project.

  34. Jonathan West says:

    Using XCode can you compile just to PPC and so evade these problems for a while, or can it only compile to Universal Binary?

    Is it your intention to re-introduce VBA in the version after?

    By the way, it appears that from the way that you are using the words interchangeably you are not distinguishing between "users" and "customers". In the corporate market, "users" mostly don’t individually buy software, their employers usually make a central purchasing decision. Although most users in a corporate environment have no idea of the existence of VBA, if the company makes some use of VBA in templates or add-ins provided to their users, then this becomes a deal-breaker.

    We can agree to differ as to whether this will be a sufficiently common situation to constitute "abandoning" the corporate market. I rather suspect that your corporate upgrade sales will severely slump.

  35. Rick Schaut says:

    Jonathan, your first question reaches down into areas where I don’t know the details.  Yes, XCode can build PPC-only, but I believe the issues were related to GCC.  Schwieb touched on it, so read his post again.

    As for what we intend to do for Office Next, I really don’t know.  At this point, there are too many unknown exigencies to say what we plan to do with any confidence.

    The "users" vs. "customers" issue is a valid point in general.  I was a bit opaque in that I didn’t explicitly discuss how the specific user scenarios map to general customer decisions in different corporate settings.  I suppose I can be less opaque, but I’m not sure where that gets us.

    The kind of feedback we need to hear now needs to be more specific than just generic "corporate" discussions.  We need to hear about what customers are doing now that will need to be changed because of this decision.  A good example is a comment someone left on Schwieb’s blog about "Wordfast."  We need to hear how VBA solves customers’ problems.  We might be able to come up with alternate solutions that, in the long run, will be better for those customers.

  36. Jonathan West MVP says:

    OK, let me tell you that every one of my templates for corporate customers uses VBA (about 1000-2000 lines per template), called from keyboard shortcuts and buttons on custom toolbars, for doing such things as the following

    – setting styles

    – inserting custom tables

    – reformatting pasted tables to custom style

    – setting landscape pages with automatically adjusted margins, headers and footers

    – handling list numbering

    – dialogs for entering information onto cover pages

    – handling special cases for printing

    – creating new document based on custom templates

    – Setting user information to be automatically included in a sign-off block

    – Inserting graphics &/or charts automatically sized as appropriate

    My customers aren’t going to be pleased at the idea that every one of my templates will immediately stop working when they upgrade their copy of Office, and that (where they are mixed shops) future upogrades will cost double because I will have to do the coding twice – once for Mac, once for PC.

    Much of this could be done with a largely common codebase before – not in future.

  37. Alan Stouder says:


    I’ll second Jonathan’s posts, we sell software for law firms and use VBA for integrating Office and customers are not happy.

    Our customers using Macs have already asked about moving to Windows because of the risks and lack of integration of the Office Mac suite with the rest of the IT world (btw the Office Mac June release was a first step in the right direction).

    OK, you’re dropping VBA for the next release to speed the release of the next Office, but the real second thought is mostly internal since VBA development is frozen on Windows too. We already had to rewrite our VBA code in VB6 in order to support Outlook. And now we are considering the conversion in 2007…

    If we keep our customers on Mac, we will have to rewrite our VBA code with Applescript but we don’t know how to manipulate Dialogs the way we do with VBA, and a lot of issues are left open with the conversion from VBA to verbose-oriented Applescript.

    So I really hope your team releases a 1st-class Office developer documentation for Applescript to help pass the pill for the VBA-killing.

    And thank you for sharing your info on this blog, I hope the MacBU will keep its corporate customers!

  38. Rick Schaut says:

    Jonathan and Alan, thank you very much.  That’s exactly the kind of feedback we need, and I’ve already forwarded your comments to the right people.  Also, feel free to send me further comments using the Email link at the top-left of the blog home page.

  39. Man, if I were you, I would find a way to punish Apple for doing this. If they had only told you from 2000 to start using xCode because the future is uncertain, we might move from PPC to Intel, then you would have had the time to port properly.

    From the sound of everthing, Office Mac development just sound very uncertain.

  40. Rick Schaut says:

    Andre, punishing Apple doesn’t help users in any way.

  41. I know Rick, but its so frustrating. They know that Mac Office is vital to the platform, so at least have the decency to tell your biggest partner’s to start trasitioning to xCode because the future of PPC for us is uncertain.

    Steve Jobs told attendees at last years WWDC, Mac OS X has been compiled for Intel since 10.0. After Office X was released, they could have given you guys the warning, that would have been early 2002 which would at least given you some time to continue developing the last PPC version (Office 2004) and start on the next UB version (Office 12).

    The same applies to Adobe, Apple is making this really difficult and if I were you guys I would give them a stern warning never to do this again.

    Their paranoid secrecy tactics have gone too far in my opinion.

  42. That assumes that Apple had a clear idea, seven years ago that this was an option. 2000 was pre G5, Pre Core Duo, hell, a chunk of it was pre Mac OS X.

    The G4 at the time was a far more power efficient chip than the Pentium, and the world was a different place.

    And that whole punishing thing? This isn’t a sixth grade schoolyard.

  43. Jonathan West MVP says:


    Apple aren’t the only people to do this trick. Microsoft themselves did it to all their VB customers a few years ago – and it is still remembered. (Take a look at for more details.) I lobbied hard at the time to try and ensure that Office VBA didn’t go the same way – giving precisely the same reasons then as I have on this and Schweib’s blogs. Up until now, it has been OK, and I think that the Windows Office group does understand this. When I attended the MVP Summit attended last year, lots of demonstrations were given of how to develop in Office 2007, and the Microsoft people were falling over themselves to say "and you can do just about everything in VBA developing for Office 2007 that you can do using .NET".

    I must admit that when I first read the platform problems in Schwieb’s blog, my first inward reaction was "At last, now Microsoft might understand how it feels to have a platform pulled from under you. Maybe they will decide that their reputation requires that they don’t inflict the same pain on their own customers".

    But alas, that seems not to be the case. Microsoft has decided to delegate the rewriting task to its customers – again.

    Rick, could you say when this decision was taken?

  44. Rich Shields says:

    How will the AppleScript-for-VBA switch will work in the future in terms of interoperability with the Windows side of Office? According to Excel discussion forums (and I imagine the same for Word), there will not be a smooth transition between VBA and Many claim that they will have to re-write code, even on the Windows side. If that is the case, what will happen when it is AppleScript and It would seem that Office integration will be further away than even VBA issues you and scwieb wrote about.

    Am I missing something? (As old as I am, that is entirely possible.)

  45. Rick Schaut says:

    Andre, et. al., I’m calling a halt to any discussions about retaliation against Apple.  I’ve agonized about this, because it means not approving some comments.  While I do value a free exchange of ideas, this particular discussion is one I just can’t have on my blog.  Those whose comments have not been approved all have blogs, so you can say what you want to say in your own blogs.

    Jonathan, I don’t know when the decision was taken.  I’m not sure if I could tell you if I did know.

    Rich, you’re not missing anything so much as delving into a future that remains uncertain even for us.  As I said earlier, what we really need from users/customers now is information on how they use VBA, and what problems they solve by using VBA.

  46. J. P. Ransdell says:

    I am not a computer programer, I simply use a compter as a tool in professional and private life.  To do my job, I even have to use several "programming languages" including VBA, HTML and Flash.

    1.) At first, the announcement that MS would stop supporting VBA horrified me.  Currently the way I use Excel to do data analysis requires VBA.  And the files need to be compatible on Windows machines and Apple machines.  I see no other alternative in sight that fufills this requirement.   Why am I looking for this feature?  Because I have to be able to send the file to my boss and let him play with the different scenarios I code in VBA for Excel!!!  I tried to use the scenario manager for this task, but it just wasn’t powerful enough to actually replace formulas as well as values.

    2.)  I am now hoping that MS will announce the usage of a common scripting language for Windows and Apple office suites.  In fact, I wouldn’t be mad at all, if MS simply announced said something like, "Dear customers, the future scripting language for MS office will be, say, ‘script x’.  Unfortunately, due to technical difficutlies, office for Mac will not be in a position to support legacy languages like VBA, so Mac users are encouraged to trasition rapidly to ‘script X’"

    3.)  In the meant time, I am looking for alternatives to Excel and VBA, but I haven’t really found any yet.  MS really has a unique product here.  But, the threat of taking my Excel with compatible scripting language away is certainly creating a market for another product.  In any case, I really don’t see the use of wasting my brain power with something like Apple Script.

    That’s my 2 cents for your marketing department….

  47. Michael says:

    Rick, you said: " I just don’t quite follow the logic that has us purposefully leaving real money on the table just to spite Apple.  Is there some reason you have to think that we’re that stupid? "

    Nobody thinks Microsoft or the Mac BU is stupid.  But there are plenty of calculations on the matter which might lead to shafting Apple & Mac users.

    Here’s one, which I would certainly have looked into were I in Microsoft.

    Apple has ~5% of the market. MS would ideally like that 5% for itself.

    What percentage of that 5% is either corporate or needs corporate cross-platform compatibility (I mean *real* compatibility, and so I mean VBA compatibility)?

    If it’s a significant proportion (and I bet it is) then it makes business sense to lock them out of the compatibility they need.  Result? They either (if corporate) ditch Macs altogether or (if outside the enterprise — consultants, freelances, SoHos etc) have to buy (a) Windows and (b) Windows Office if they want to keep their Macs AND their compatibility.

    You don’t need a spreadsheet to see where the money lies. If I could sell either one Office Mac upgrade or one Office Windows AND one Windows OS, I know which one I’d go for.

    Unless I really, really didn’t like p***ing off my customers.

    Which I wouldn’t care about that much if I was Microsoft, and if I were slowly dragging them through the Borg Gate anyway.

    It’s not stupid. It’s smart.

    And it stinks more for being smart than it would for being stupid. Stupid can’t help it. Smart can, but won’t.

    See, we aren’t that stupid, either. We’re just impotent. Doesn’t feel good.

  48. Rick Schaut says:

    J. P., thanks for the feedback.  That’s exactly the kind of information we need.

    Michael, you presume that one Win Office upgrade plus one copy of Windows nets Microsoft more revenue than one Mac Office upgrade.  That presumption fails to take into account the manner in which these different software packages tend to be sold.  There’s a spectrum of licensing options including volume discounts and subscription services.  Under the licensing options that some organizations have chosen, should those organizations move people from Mac Office to Win Office, Microsoft’s revenue loss will be equal to the entire upgrade costs of Mac Office.  For those organizations, the additional usage of Win Office and Windows would bring 0 revenues to Microsoft.

    An interesting number to think about is Microsoft’s revenue per unit of hardware sold.  Do you think Microsoft makes more money per Windows PC sold, or does Microsoft make more money per Macintosh sold?  I’m not at liberty to discuss our more recent revenues, but I can say that even back in the hey-day of Windows 3.0, Microsoft still made more money per Macintosh sold than we made per Windows PC sold.


  49. Chris Till says:

    Fascinating to read that Word:Mac and WinWord no longer share the same codebase – I was aware of the major sync that took place with Word 6 (not just for the Mac, but for WinWord2 to WinWord6 as well) but didn’t realise it never continued beyond there.

    I’m shattered VB is to die – not only from the simple situation of a bank sending you a homeloan spreadsheet that will no longer work, but I had always hoped that VisualBasic itself would someday make it to the Mac after the death of QuickBasic (something nobody seems to remember?).  Surprises me that Mr Gates has let RealBasic get to where it is, I always though he considered BASIC to be his prized puppy… anyways beyond the entire point of this discussion.

    So am I right in understanding even VBA on Windows is changing now?  That’d be a third language for Word – WordBasic, VBA, and now something else… that new evolution isn’t something that can/is being readied for the Mac as well?

  50. A collection of some good posts by other Microsoft bloggers to tell a tale about quality in software development.

Comments are closed.

Skip to main content