Some gory VBA details

I found a great link the other day describing the decision to drop VBA in the next version of Mac Office.

Here it is

Well worth a read (its long mind), although I’m not sure if it gives those of us in the Windoze world any guidance for the fate of our beloved VBA.

In the ‘Future of VBA’ session at the conf I estimated 2020 something. Anyone else prepared to stick their neck out?

If you have time to read that whole post and all the comments (and you probably shouldn’t!)(I still did it though – thats another hour of my life I’ll never get back). But if you do there are some really juicy gossipy tidbits. All pure blog sphere gossip, could be completely untrue, in fact almost certainly is untrue actually.

Jonathan said: ‘Steven Sinofsky (at the time the Group VP in charge of Office) has made several public statements that VBA would remain in for “at least the next two full product cycles” of Office. The first of those is Office 2007’

Richard said: ‘nd that office for x86-64 is dropping VBA support.’ [Anyone else heard this? I’m not convinved]

Nick Hodge? Nick Hodge? Oh, its the other one, not the ‘real’ one.

Various: a version of .net for MacOS might solve all the issues (and re-align the Mac and Win programmabilty story)

Various: Dropping VBA is the start of the end for MacBU.

One interesting factor from a business POV is that the single shining USP (unique selling point) of Mac Office is Win Office compatibility I’d have thought? surely?

I don’t recall ever reading advice that dumping your USP was going to improve business.

Also interesting was the mention of difficulty filling vacant roles in the MacBU. I’ve seen this mentioned elsewhere about MS in general, and the fashion to want to work at Google instead.

There is a good technical explanation of some of the guts of VBA that are almost universally derided by the commentors. Personally I suspect that code is hard to maintain because it was coded to eek out the maximum performance on a platform less powerful than a modern mobile phone. Not because the coders were ‘brain dead’. (That and the fact there are few C coders still coding now)

I had my win 3.11 lapper with Office 5.0 at the conf, circa 1993 vintage.

80486 proc, 640k RAM, 163 Mb Hard drive. [Edit – caught red-handed by Harlan, there is 3 Mb Extended Ram too]:

win sys

VBA was conceived, designed, coded, built and tested before that time, and worked acceptably. And I bet some of the guts of the Excel calc engine hail from that era too.

I really don’t agree with the often stated modern view that performance is not an issue anymore. Maybe not if you are waiting for a web or database connection or user input action , but for the number crunching I see and do, performance is extremely important. What about you?

Cheers

Simon

Advertisements

8 Responses to “Some gory VBA details”

  1. Ross Says:

    >>but for the number crunching I see and do, performance is extremely important. What about you?

    Yes, very much so. I think it is for a lot of people, but it’s the easiest thing to avoid as making SS fast is actually quite hard?

  2. Harlan Grove Says:

    You’re fibbing about your 1993 machine a bit. Windows 3.1 wouldn’t run with less than 2MB RAM, though the upper bit would have been extended memory.

    Agreed: performance is still valuable, and is too often ignored, though I’d add resource parsimoniousness to execution speed.

    As for .Net on Macs, since OS X is a heck of a lot closer to Linux than Windows, I’d suspect it’d be quicker & easier to port Mono than .Net to OS X, but Microsoft isn’t about to contribute to a GPL’ed project. I have to say it’d be a measure of .Net’s/Mono’s usefulness if no outside programmers bother to port Mono to OS X.

    Would a Mac VSTO really be more efficient for Mac developers than what they already have? Flip side: is there any commercial software (meaning anyone could buy it and run it, as opposed to custom software written for specific clients) written with .Net?

  3. Simon Says:

    Harlan – My bad, there is indeed 3Mb of extended Ram – Post updated to fess up.

    Good point on .net/Mac – if MS do the port it would reduce the criticism for kneecapping Mac Office. I can’t see it though can you? (Although they are helping Novel with Moonlight, so maybe via the back door?)

    Software vendors are starting to release .net based apps slowly, from what I have seen generally using a 3rd party linker to avoid the framework distribution responsibility.

  4. Harlan Grove Says:

    Am I reading the linked article right? By ‘GCC’ the author means the GNU C Compiler? Microsoft uses GCC for Mac software development?

    There are other BASIC programming development environments for Macs, just not VB proper. Can VBA not exist without VB? I can understand why it’d be a pain to rewite, but by dropping VBA support they’re either figuring that Mac Office developers would prefer AppleScript or that Mac users who use Office mostly use Macs that could run Windows versions of Office in Windows VMs/emulators.

    To me the latter seems more likely, so I have to wonder whether making Mac Office VBA-free is meant to hasten uptake of Windows Office under VMs on Macs. That is, I agree with those respondents who believe the Mac Office team are programming themselves out of jobs.

  5. Stephane Rodriguez Says:

    Simon said “Software vendors are starting to release .net based apps slowly, from what I have seen generally using a 3rd party linker to avoid the framework distribution responsibility.”

    The .NET 3.5 run-time redist is 197 MB. This just made my day.

    Harlan said “There are other BASIC programming development environments for Macs, just not VB proper. Can VBA not exist without VB? I can understand why it’d be a pain to rewite, but by dropping VBA”

    I don’t buy it either. It’s not like Microsoft can’t hire a few guys to help those in MacBU, is it? Or even better, that they ask SummSoft (already doing a ton of things on Windows VBA and VSTA) to do the Mac port. Sounds indeed more like canning/strategy.

  6. Simon Says:

    Stephane – 197Mb? Xenocode etc must be rubbing their hands in glee.
    The article specifically states MacBU struggle to fill vacancies – would you work there? (job security???).
    MS are labouring under the misapprehension there is still some kudos to working there, yet all the cool cats want to work at google or apple from what I see. MS probably need to revisit their remuneration packages if they are understaffed.

    Its hard to see how dropping VBA is anything other than punishing apple for its success, unless there is some bigger strategy around Office Live or something?

    Mind you Stephanes Ideas around software apps as virtual machines totally solves this.

  7. Stephane Rodriguez Says:

    “The article specifically states MacBU struggle to fill vacancies”

    I know a ton of companies with a jobsite filled with vacancies, and the HR department taking no resume seriously. The cynical in me thinks it’s just part of the public image Microsoft is willing to give about MacBU (while making their lives miserable).

    As for working there, I don’t think Microsoft would even consider an actual hire for what is a clearly identified contract work (the blog post you have pointed is pretty much the specs of it).

    VBA and Office Live? Microsoft knows all too well that they can’t put too much power in this without undermining their own client cash cow. I’m not holding my breath. And that’s probably the reason why Excel services does not run VBA macros either (I hate to think that they are probably explicitely branching off this scenario in the Excel services code).

  8. Stephane Rodriguez Says:

    “The article specifically states MacBU struggle to fill vacancies”

    I know a ton of companies with a jobsite filled with vacancies, and the HR department taking no resume seriously. The cynical in me thinks it’s just part of the public image Microsoft is willing to give about MacBU (while making their lives miserable).

    As for working there, I don’t think Microsoft would even consider an actual hire for what is a clearly identified contract work (the blog post you have pointed is pretty much the specs of it).

    VBA and Office Live? Microsoft knows all too well that they can’t put too much power in this without undermining their own client cash cow. I’m not holding my breath. And that’s probably the reason why Excel services does not run VBA macros either (I hate to think that they are probably explicitely branching off this scenario in the Excel services code).

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: