Licensing the crown jewels

I believe VBA plays a key role in keeping MS Office in enterprises, and I believe MS Office plays a key role in keeping Windows in enterprises.

Sure there are plenty of other factors, but these are important in my mind (could be biased by my experience in this area of course).

Stephane made a point in a comment that reminded me of an interesting snippet.

Microsoft used to licence VBA (the IDE, the run times etc) to anyone. As a vendor if you want to add VBA scripting to your app, all you need to do is expose the right bits in the right way and your customers can automate your product with VBA. Whilst this isn’t a 10 minute job, its a damn site easier than creating a scripting language from scratch and writing your own programming environment to host it.

Now they only licence VSTA, the .net based equivalent, VBA is no longer available to other vendors. (This change might have been a factor in the incorrect (/premature?) reporting of the demise of VBA)

I wonder if they have(/had) a restriction to prevent the use of VBA on products that compete with Office?

I know at least one open source spreadsheet project that was contemplating licensing VBA from Microsoft. I wonder what would have happened if they had done…

It makes me wonder how wise it is for Microsoft to be licensing what I would consider a key technology? I guess its ok if they have restrictions on the type of use, what do you think?

The fact that Proclarity, Autocad etc have VBA adds to VBA’s appeal as a language to learn I guess.

What do you think?



10 Responses to “Licensing the crown jewels”

  1. Rob Bruce Says:

    AFAIK Quattro Pro has had full VBA since version 9 around the turn of the century.

  2. Stephane Rodriguez Says:

    My ex-employer, BOBJ, has full VBE integration too as part of the Full Client. All you need (all you needed…) is the $license$, and the SummSoft VBA SDK. But now that the FullClient product is reaching EOL, and Webi won’t use VBA, I guess this has become a non-issue over there.

    And yes, FullClient did not compete with Office, no matter how the original FullClient developers reproduced the best things from Word and Excel…Perhaps that explains why Microsoft licensed it to BOBJ. BOBJ customers were requesting en masse it since they were already trained with VBA/VBE. It seemed so natural.

  3. ChipG Says:

    I use ESRI’s ArcGIS for mapping, and it has VBA, which I have found to be invaluable, though the object model is quite complex.

    Just last night I reread some of Walkenbach’s book on UserForms, and created one to polish up some stuff I’d been doing on a one-off comment this line/uncomment that line “system.” I don’t have the time to learn another programming language and environment, so this was a deal-maker as we were deciding on a product. I learned afterwards that there’s also a vibrant community support group on the ESRI boards, from which I’ve gotten most of my code snippets that do the heavy lifting in the maps.

    So, is it smart for MS to have licensed it? I think it was, since it means that I tie more of what I’m doing in a non-competitive product back to what I’ve learned for Excel and Access (and even Powerpoint.) That adds value to the investment of time I’ve made in learning VBA for the MS products. Maybe if I learned another language that can be used to manipulate ArcGIS (there are several), I would prefer it over VBA, and would then tend to migrate other work that way.

  4. Simon Says:

    Thanks guys, all good points.
    I think a ‘universal’ application scripting language is a brilliant concept. The potential synergies are immense for anyone who makes the effort to pick up even a fraction of the language.

    Sadly I think MS have given up on VB languages, I hope they get over it.

  5. Harlan Grove Says:


    Quattro Pro 9 and 10(? the one in WordPerfect Office 2002) had ‘PerfectScript’ and 1-2-3-like in-worksheet macros. It didn’t have VBA. [And it had a flaky HTML help system even worse than Excel’s.]

  6. Jon Peltier Says:

    “So, is it smart for MS to have licensed it?”

    Definitely. Don’t just look at each application on its own. At my last job before going solo, the engineers had to communicate with the plant’s archaic “database” (if you’d call it that) through a telnet program. You know the kind, one prompt at a time, entering one parameter at a time. Well, I discovered that the company had uncharacteristically bought a high-end telnet program with a VBA interface, and I had Excel doing my queries for me. It was saving at least an hour a day. I was within a week or two of sharing it with my coworkers when they laid me off. Probably I was screwing around on the computer too much.

  7. ChipG Says:

    “high-end telnet program with a VBA interface”

    Who knew that such a beast exists?

  8. Jon Peltier Says:

    >>“high-end telnet program with a VBA interface”
    >>Who knew that such a beast exists?

    Well, I was surprised, but poised to take advantage of it. The week before I was canned, I got in a fight with the IT guy, a VB programmer about how we engineers were forced to work. Not only did we have to telnet the info in and out, but this Einstein wanted to have us enter the data a second time, into an Access spreadsheet, so various people could review it. This was in a meeting of us engineers and the Duh-rector of Engineering, who had commissioned the Access anchor.

    I told him to get the data himself, because we had no time for added busywork.

    He said, no can do, it’s locked up in the mainframe.

    I said, I’m doing it now, interfacing Excel with the telnet program.

    He said, that’s not possible.

    I said, come ON, you’re the VB expert, you should know this. The telnet interfaces with VBA, so set a reference and start writing code. I’ll even share with you my code.

    He’s like, but the data ins’t in fields, it’s all strings of text.

    Said I, doesn’t every decent programmer know how to parse text?

    This wasn’t the first time I’d locked horns with the VB schmuck. He’d built a system that pulled process information real-time off of our big factory equipment. Actually did a pretty good job. Then he built a POS front end for the engineers to use, which allowed you to view a single run from a single machine. If you wanted to compare it to another run, you had to print the first, load the second, and print it.

    Well, the data lived in CSV files on the network, so it wasn’t long before I figured out where they were and had built an Excel front end that let the engineer select by job number, equipment number, date, or whatever, and load as many runs into a chart as RAM allowed. Soon all the engineers were using it.

    Then one day I started getting calls from engineers, saying my program no longer was working. The VB guy had upgraded his front end, so now you could view up to eight runs at a time, as long as they were from the same day. He’d also moved the data files to a different network drive, so my Excel app didn’t know where to look.

    When I confronted him, he said his arrangement was more secure. You could’t give the engineers open access to the data files. He couldn’t tell me why he’d moved the files from one read-write directory to another, and while I was there the data was never made read-only. More secure.

    I like working for myself much better.

  9. Jon Peltier Says:

    Wow, I didn’t mean to be so long-winded.

  10. Rob Bruce Says:


    Are you sure? There’s a review here – – that states that QPro9 had VBA, though magazines have been known to review pre-release software that contains features that are left out of the RTM product.

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: