Its finally dawned on me.

After months and months, or maybe years and years. I’ve never understood why MS don’t seem to see VBA as the same lock-in factor that I do.

I havent been watching the migration projects – they have.

I’ve recently been looking at some of the wins for OpenOffice in the last 12 months here.

I hate to say it, but MS are right and I am wrong.

It seems that in most OpenOffice deployments some proportion of power users (and users with disabilities) end up using MS Office. For the power users it is their requirement for VBA that keeps them on MS Office. In the Bristol City migration they kept the proportion on MS Office under 15%.

Also I didn’t read of any related moves to Linux, so maybe I got that wrong too?

So VBA is a lock-in feature but only for upto 15% of users. I’m guessing from Microsofts POV 15% is not much of a lock-in. And probably not enough to justify the new VBAIDE I keep asking for. And I’m sorry I can’t see how the ribbon provides any lock-in, just the opposite in fact, in my opinion.

I imagine SharePoint and the rest of that server tangle offer a better chance to encourage a higher proportion to use MS Office.

So finally it all starts to make sense. And in fact what about interoperability, won’t that mean that non MS products must be able to read and write all parts of Office XML, including the VBA blob?

I’ve done projects before where VBA was banned, and it can be a real ball ache. I imagine if you are targeting both OOo and MSO users VBA would be out, which leaves you potentially creating a spreadsheet monster that 50 lines of VBA would totally tame.

What do you reckon? have you seen this new mixed environment? How would you feel developing for that world? Could Sharepoint be our saviour from the pain of targeting multiple spreadsheet applications? (never mind the pain of multi-version stuff!). Do you work somewhere that currently uses a range of spreadsheet apps?




3 Responses to “Bing!”

  1. Harlan Grove Says:

    Re VBA blob in OOXML files, are BOTH .XLSX and .XLSM approximately ECMA OOXML-compliant or is only .XLSX (i.e., without VBA)? If only .XLSX, VBA would still be propriatary and .XLSM files wouldn’t be OOXML files (or would be mostly OOXML but with substantial additional non-OOXML bits).

    If Excel/SharePoint integration is anything like 123/Notes integration, it shouldn’t be too bad, but VBA won’t be part of that blissful picture except when opening Excel files stored in SharePoint libraries (? I don’t know the terminology) under Excel clients, so as if the files were opened from local drives.

  2. Stephane Rodriguez Says:

    “read and write all parts of Office XML”

    I already feel for anyone going down the path. Soon they’ll regret the beauty of the so-called old and cranky VBA engine. Hint: if you are not running an instance of Excel, you lose all what keeps the spreadsheet in sync for you.


    “OOXML-compliant” : Microsoft novlang for compliance regarding OOXML is that it is purely syntax (as stated in the scope section of ECMA 376). Rob Weir made a joke on that, noting that the DOS copy command has rich support for OOXML since it is arguably fully compliant with it.

    Seriously though, the only difference between .XLSX and .XLSM is that with the latter it instructs the Excel file loader to ignore whatever VBA parts are stored in the file. But you can have VBA parts in .XLSX files, no matter how the Excel 2007 UI tries to kill them when you save. (another example of user drama when clicking OK kills the VBA parts permanently, a first in Excel history IMHO)

    In regards to VBA and sharepoint, Microsoft has a problem : VBA is a COM apartment. It’s single-threaded. (it’s old stuff, after all). It totally kills the virtuous “multi-threaded Excel services” product right at bay.

    Even better is what happens to all this stuff when you run it on a 64-bit machine. I’ll post about that later… (hint : not nicey)

  3. Stephane Rodriguez Says:

    I have promised an update on Excel 2007 and 64-bit OSes, so here we go.

    I recently setup a machine with Windows XP 64 edition to create a 64-build of my product, as the demand from customers is growing. But my build includes tests targetting Excel (both old and 2007). And that’s when the fun begins.

    1) There is no 64-bit edition of Excel 2007. I intentionally don’t mention the rest of the Office suite, but don’t expect any difference. When you double-click on Excel.exe, it starts under the WOW32 layer.

    2) The point above has a number of consequences. The first is that add-ins built for a 64-bit target won’t load in Excel 2007. In case you wanted to take advantage of the huge memory or the new CPU instructions, bad luck.

    3) A huge concern for performance of Excel 2007 is that a 32-bit program gets through the WOW32 layer which virtualizes memory access back and forth, and takes a substantial hit. Don’t ask me about Excel services, I don’t know the answer (yet) but this is problematic to say the least.

    4) It gets worse. No 64-bit edition of Jet drivers. Sure this stuff is old, but how many applications use Jet out there? All broken now when used in an application built on 64-bit. (PS : Jet = database drivers for Access, and so on). Installing Access 2007 does not fix the problem. No 64-bit edition of Jet drivers, period. But of course, native 64-bit SQL Server drivers are available. Self-serving, anyone?

    5) No 64-bit edition of VBA. Remember, there is no VBE anymore in Excel 2007 since it was integrated and hidden in Excel 2007 itself. But VBA still lives outside. Unfortunately, no luck.

    6) No 64-bit edition of OWC (Office Web Components), an alternative set of visual components (ActiveX control) that mimics Excel for free (view, edit, grid, chart, pivot tables). Again, any application that used OWC is simply broken unless the application is forced to run under WOW32. But it’s not always an option. Any 64-bit dll cannot load in a 32-bit exe, and vice versa. When Excel is sold as a developer platform (read : numerous ways to load your stuff within Excel’s process), this sounds audacious of the Office team to have ignored the issue.

    7) .NET assemblies loaded in Excel.exe can only be 32-bit, for the same reason than all the above.

    The only logical conclusion is that either Microsoft doesn’t believe in 64-bit systems (even though I can attest the demand is growing), or the Office team does not want to pay for the additional work. Curious, in retrospect, that they have rushed Office 2007 out the door (at some point in time, they wanted that Office 2007 RTM with Vista RTM, in 2006).

    PS : I have verified on the MS download site that all the above does not exist in 64-bit edition.

Leave a Reply

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

You are commenting using your 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: