So tell us what you want, what you really really want!

Thank you all for your comments about VB. There’s certainly a lot of passion, frustration, and outright anger being expressed here. For those of you with kind words, I greatly appreciate them. We’re reading every comment, no matter what the sentiment. I’ve personally seen MacBU leads reading your comments on my blog.

I had intended to post yesterday and answer some of the specific questions raised, but I’ve once again caught a nasty fever and cold from my preschool-aged son and didn’t get to it. Sigh… In lieu of that, I’ve got a couple of more general notes to make on yesterday’s post.

In my note on resources, I used a slightly extreme example of our headcount. I did have an opening for quite a long time, but our overall delta between having someone leave our group and hiring a replacement is probably something like 2 months or so. I have no idea how that compares to any sort of Microsoft- or industry-wide average. The complicating matter is that departures and candidates tend to happen in clumps, so we often end up with some abnormally long or short gaps in staffing instead of a more normal distribution. We’ve actually had a lot of folks very interested in working at MacBU (i.e, us having open headcount really is not due to a lack of people interested in working here). We hire world-class developers and they don’t simply grow on trees. For those readers offering a smackdown on the intelligence or capabilities of our developers, nothing could be further from the truth. We’ve even had some developers leave MacBU to go to other renowned Macintosh companies and then come back to MacBU because the grass really wasn’t greener elsewhere. We’re all proud to be here!

As for keeping VBA in PPC to run under Rosetta, that could be done but just vastly overcomplicates an already very complicated piece of source code. Rosetta only works on a per-process basis, so we’d be moving code and data out of the single app process into two processes. There are many many points in which apps call into VB and VB calls back into the apps (not to mention VB’s dependence on other lower-level shared library code that is now Mach-based) and marshalling all those calls and data cross-process is a heck of a lot of work. It gets even more complicated when you have more than one Office app running at a time, because then the new VB process would have to keep its internal state separate for each client app!

People have also offered the solution of porting the current Win Office 200x VBA over to the Mac. That’s pretty much a no-go too, because 1) it still has the assembly ABI problems, 2) makes calls to the Win32 APIs that don’t exist on the Mac (well, without WINE or any of the variants) and 3) relies on features in the Windows OS that don’t exist at all on the Mac. We’d have to port over large swaths of the Win OS and that might take even longer than writing VBA over from scratch.

VBA just wasn’t designed to be portable across architectures. The Mac and Windows implementations are very different, even though the actual language is the same. If I could go back in time about 15 years and tell the original designers to do it differently I would, but I can’t. Thanks to the heroic efforts of a few developers (Shuyi and Ying) we managed to Carbonize VB for OS X, but the move to Intel is gargantuan. We considered many, many alternatives. Each one turned out to be no simpler and as much or more work as the plain port would be.

None of this is work that we can’t do, it’s just work that would take away from everything else that we do want to do and would delay shipping Office 12. As I said on Tuesday, delaying Office 12 has other ramifications for cross-platform compatibility such as dealing with the new Office XML file formats and related features (like the larger cell grid in Excel, for example.)

Back to the idea of AppleScript… Folks who want to develop scripting modules on the Mac should check out AppleScript Studio. You can create GUI applications with it, and it is absolutely free from Apple. Also, a few bloggers have been wondering about scripting Office with Python and other languages. Yep, you can do that with the AppleEvent bridges available for those languages. We actually test Messenger in-house with a large suite of Python scripts that drive it through OS X’s Accessibility AppleEvent suite. We also drive Xcode via its AppleScript dictionary with Python scripts that send AppleEvents.

So, what now? Well, it is pretty obvious to me that the MacBU needs to provide some guidance for folks who currently use VB. The best way for us to provide the information that will help you the most is for you to give us some first. I encourage you to provide feedback to us — lots and lots of feedback! There are several ways you can do this:

  • Select Help/Send Feedback on ‘OfficeApp’ from within your favorite Office 2004 application
  • Click on this link and fill out the web form
  • Post a comment on any of the MacBU blogs
  • Send me email from this link and I’ll forward it into MacBU

Please give us specifics in your feedback. Just saying “I want VB!” or ranting about how we’re evil doesn’t provide us anything we can take action on. We’d like to know what you do with VB, what the goal was, did you share the macro with anyone, was it specifically cross-platform or just something on the Mac, what app was the macro in, and things like that. So yes, do tell us what you really want. Please keep it civil, it’s no fun reading through pages of insults. Your feedback directly helps us figure out the best ways we can help you.

[Aug 11, 9:26am — minor edit to correct the description of how we drive Messenger with Python]

Published by


Married with two kids, one cat, and 4 computers...

110 thoughts on “So tell us what you want, what you really really want!”

  1. Okay here are some very specific things I would like to see in Office, mostly excel.

    1. How about a feedback option where users can submit bugs, suggestions and feature requests similar to Apple’s iLife products.

    2.A plug-ins set of programming templates that would be installed if xcode is present. Those who would like to write plug-ins would have the tools, interfaces and libraries present when they launch xcode.

    3. Excel specific- How about a collection of BitWise functions like
    value1 is an integer value of byte size “size” (1,2,4,8,16,32,64,128,512,1024)
    value2 is an integer value of byte size “size” (1,2,4,8,16,32,64,128,512,1024)

    Returns an integer value of same size.

    BitAND(value1, value2, size)
    BitOR(value1, value2, size)
    BitNOT(value1, value2, size)
    BitXOR(value1, value2, size)
    BitNAND(value1, value2, size)

    Bit test would be slightly different with value2 = to the 0 based index of the bit you wish to test (assuming a BigEndian formatted number)

    BitTEST(value1, value2, size)

    4. Excel based function. GetItem(string, item, del)

    Returns a sub string containing the item “item” of the string that is delimited by “del”.

    For example a string formated “fe80:0000:0000:0000:0216:cbff:fec0:c479”
    GetItem(“fe80:0000:0000:0000:0216:cbff:fec0:c479″,3,”:”) would return “0000” as its value.

    5. Excel based function SetItem(string1,string2,item,del) would replace item “item” in string1 with the contents of string2 using del as thhe delimiter.

  2. This thread is old, but since the problem isn’t going away anytime soon, I feel it’s OK to add my comment anyway.

    1. I don’t like Office. I think it’s ugly, confusing, slow, irritating, buggy, and generally rotten beyond description. I think Office isn’t even worth the HD space it takes up, never mind the considerable amount of money it we have to pay for it.

    2. Despite my strong personal dislike, I always buy Office and install it on all of my computers. There is one single reason for this: Other people insist on producing .doc and .xls files (forgive them Father, for they know not what they’re doing), and I need to be able to open them. I’d certainly never tie any of my own work to these untrustworthy and proprietary formats, and keep praying with fervor the rest of humanity will come to it’s collective sense, but until that cold day in Hell comes to pass, I do need Office.

    3. If a future release of Office looks any more or less like it belongs on a Mac is completely beside the point. It could look like it belongs on a Commodore 64 for all I care, I don’t like it anyway, and avoid using it whenever possible. The day I don’t have to start up Office at all is a happy day indeed!

    4. The question whether feature X should be added or feature Y dropped from Office falls completely outside of anything I’d ever care about. I’ll be certain to use feature X precisely as much as I have previously been using feature Y, that is not at all, ever. Feel free to add as many paperclips and puppies and wizards as you like, it matters not the least to me. The ONLY feature of Office that has any value whatsoever to me, is the feature of being able to open all the .doc’s and .xls’s produced by those unwitting people out there (bless their ignorant little hearts). Amazingly perhaps, I’ll pay a stiff price for that feature alone.

    5. A new Office version that cannot open .doc’s and .xls’s reliably is as useful as a – sorry, my imagination isn’t vivid enough to imagine anything equally useless to compare it with. Most useless things in this world can at least be used as doorstoppers, but the bits and bytes that make up Office aren’t even good for that, lacking the neccessary substance. No new feature of Office can possibly make up for such an inability to open the files it’s meant to open. Take away the sole reason for a thing to exist, and what do you get? Nothing.

    6. I will not install any such crippled version of Office on any machine I own, not now, not in the future. I will rather install any other combination of software that performs the necessary function, even if this should end up being a whole Windows partition with a proper version of Office to go with it. I don’t like or want Windows on my HD any more than I want Office, but we’re talking about pure necessity here. If Microsoft intends to scrap Office for Mac, and thereby force me to buy two products instead of one, it’s a sacrifice I’ll just have to make. If Microsoft decides to bleed me, I’ll bleed, simple as that. That is, unless someone else offers another solution to the sole problem uniquely solved by Office: The problem of reliably opening .doc and .xls files produced by Office on Windows. In that case I give Microsoft the finger.

    Am I alone feeling this way about Office? I think not. I understand it can’t be very fun to work on something so unloved, but the fact is, very few people buy Office because they love it, especially Office for the Mac. If you imagine otherwise you’re lying to yourself.

    What should you do then?

    You should make Office 100% cross-platform, at the very least as far as document compatibilty goes. For your own good, it should really be compiled for the different platforms from a common source tree. To have two teams working on two versions in parallell is just incredibly stupid. There’s no other way of putting it. Such an organisation wastes money for Microsoft, while at the same time guaranteeing compatibility problems for the end users. And as I said, no amount of ‘other benefits’ can possibly outweigh this! Of the two Office versions, the Windows version is obviously the reference version. The Mac version needs to be exactly the same, not better, and certainly not worse.

  3. As one of the first to comment noted, few users upgrade Office on existing machines. By dropping features from Office, you simply make the distinction between Mac and PC that much greater. It seems that Apple will be happy to fill the void that MS leaves on the Mac, and MS is happy to cannibalize the Apple user base. Personally, I see little reason to upgrade from Office 10 for Mac, and will happily be living with my PPC machine for years. By the time I buy another machine, I expect that OpenOffice will have done a lot of catching up, and will be a reasonable alternative to MS Office, and that Apple will have their iWork suite perfected. If you want consumers to buy Office for Mac, it needs to have some compelling features – and I don’t mean proprietary file formats. Compatibility and standards are the wave of the future – if MS cannot embrace the move toward open standards, it will die a slow and painful death at the hands of Apple and the open source community, IMHO.

  4. What about the idea of creating an add-in for handling the XML files?

    It would insure compatibility with newer files and ‘buy time’ for the VB rewrite which could be done in a ‘more modern method’ to allow for future architecture changes…

    What about using spawned processes to handle the macro steps? Spawn to GCC or other available language. I’ OS and Kernel ignorant but threw it out anyway.

    What about creating a ‘pro-version’ of Office for the Mac that would roll VB or a follow-on bit to add the functionality. MS wants to make more money, right? There is another way to get ‘mo’ money’…

    What about the idea of killing the PPC code for macros? Hell, I’ve bought software that wouldn’t do certain things because of the hardware that I happen to have so why would this be that much different…

    What about turning the proposal for a new Mac/Intel VB over to the Idia programming group and letting them prove why they are better than using American programmers… I mean, if they are that ‘cheap’ that everyone is flogging themselves to jump there, why not use them… Heck, you must be able to use 10 for the cost of one of the formerly employeed American programmers wandering the streets… OR, better yet, why not submit the code that you have, all of it, and allow outside groups to do the dirty work for you. I know that looks like ‘open source’ but it might work… It would help keep out of work programmers busy and keep them from writing violent porno laced video games…

    Sorry for the snark… I was replaced in a prior career by a ‘team’ of programmers in India…

    PS: Is there a version of Basic for the Mac? I didn’t realize there might be which leads me to another possibility: What about switching macro’s in Excell to another language than ‘VB’ on the mac and depricating ‘VB’ on the PC too… I’m sure that a ‘better’ language could benefit BOTH the mac and pc realm…

  5. You stated that the MacBU has two primary goals for office:
    1-Cross-platform compatibility
    2-Mac specific features, interface, etc.

    It is my experience that the majority of Mac users / Mac businesses purchase Office because it is a good program and cross-platform compatible.

    I strongly urge the MacBU to put more resources on cross-platform compatibility, and less resources on Mac specific features. Office is a good program on Windows – just give us the same. In fact, it is difficult to work with others (on Windows) that do not see the same menu options, features, etc.

    Thanks for Listening

  6. It might be just me but in the world of bootcamp i’d love to see a twin license for software. I switch between mac and win a lot and am fairly tired of rebooting to use apps which i have the other version of. This would at least let me get at the macro’s i know and love.


  7. Tim Golobic question is relevant. Do we still get all the built in Excel spreadsheet functions? I have written a ton of functions that I use all the time including using very large arrays in memory which would be horrendous if possible in Applescript.

    I am just reading the April 2007 MacTech issue on moving to Applescript from VBA. I seems like it deals mostly with formatting worksheets. Nothing about hard core number crunching user defined functions.

    This is really incredible corporate integrity.

  8. Life has to be tough at the MacBU in Microsoft, and I appreciate that this was a hard decision. My office is mixed platform of Windows and Mac, our primary work tool is Excel, and we use lots of Macros to perform all sorts of complex analyses; which we have to share with client who are all PC operations. Consequentially this means we’re not going to be able to upgrade to next version of Mac Office, but maybe we’ll upgrade Macs to Intel versions anyways and run Parallels.

    However, yesterday I was reading about Silverlight and a mini-CLR from .NET running on Mac OS X.

    Which leads me to the thought that perhaps if next Windows Office uses VisualBasic.NET rather than VBA — which seems like a sensible idea to me — it could be possible for the next next version of Office on the Mac to also use .NET?

  9. As CTO for a vendor that makes enterprise content management software that competes (and cooperates) with the likes of Filenet, Open Text, Documentum – and these days Sharepoint 2007 – I want to convey that taking the decision to dump VB without providing a future unified (.Net presumably) direction to reunify the tribes is tantamount to corporate genocide for Mac Office and therefore Macintosh.
    If that is the goal (who knows these days who is actually at the wheel), then declare it and be done with it.
    If not, and we’re supposed to believe this is an innocent product management position, it is a stupendously ignorant move that will doom the product just as Word6 did for so many years, a primary contributing factor to Apple’s time in the corporate wilderness.

    Schwieb, this is not a technical decision, regardless of your pain. It’s a political one. If you guys delude yourselves that people buy Office:Mac because it’s “Maclike”, or has great features, or is “better” than the Windows version, think again. They buy it because they have to in order to survive in an Office/Windows dominated world. They sure as hell aren’t going to buy it for Applescript.

    At a time when large (>10,000 user organisations) corporate and government customers are beginning to return to demanding cross platform compatibility for software (at least in our category), you are dumping this very capability from your own product.

    This is not about “telling you what we want to do”. Mapping feature for feature to Applescript, RealBasic or any other technology is like blowing in the wind.

    100% document fidelity must be your foundation, then and only then can you erect your stated dual pillars of “Maclike” and “Winlike” on top of it. Document fidelity is a composite of presentation AND behaviour. That means VB in your world.

    Please note that this isn’t an endorsement of the nightmare that is VB/VBA. However you guys made this bed. You have to lie in it. Weeping for the MacBU or the fact that none of you wrote this code is hardly a mature position to take.

    The only way it is acceptable to dump VB is if the announcement is couched in terms of “Microsoft is end-of-lifeing VB on all platforms as of 2008, replacing it with xxxxxx.” Try doing that to the Windows world. Not going to happen.

    Please reconsider this untenable proposition and restore confidence to what, until now, was a fantastic renaissance starting with Office:X

Comments are closed.