Visual Basic for Applications Language Specification [pdf] | Hacker News Reader

Visual Basic for Applications Language Specification [pdf]

msopenspecs.azureedge.net

84 pointstodsacerdoti38 comments

Is there any open source implementation of VBA one can add to some application with limited effort? I'm thinking about adding macro-like functionality to one of my business applications and VBA would be the best, considering my users and Excel users intersect pretty well.

I dont know about open source. But back back around 2000 it was fairly common to implement a "VBA host". It was also easy, a few dev days to scaffold and minutes to hours of dev time to expose functions. We did it with a suite of related applications (used internally by a early ebook punlisher) that interacted a lot with Office. Introspection, auto-complete and integrated help documentation all worked and technically minded editor staff could automate lots of thier work with Visual Studio provided IDE and debuggers etc

IMHO the trick is that any moderately useful and modern VBA is likely to go way beyond the base specification.

- UserForms GUI (which this does not touch on at all)

- Microsoft libraries like mscorlib and Microsoft Scripting Runtime, to get stuff like ArrayList and FileSystemObject.

- Excel VBA is kind of notorious for mixing Excel code with the VBA, using cells of the sheet as data storage, using formulas inside of cells to calculate values, etc. For example to store a list of values and sort it, they might put the data into a tab of the spreadsheet and call Excel functions to sort it inside the spreadsheet instead of building a list in VBA and sorting it in VBA.

So I think an open source useful VBA clone would probably also need to be an Excel clone and also a clone of a bunch of Microsoft libraries

I love your comment. I'm guessing that it'd be very difficult to clone Excel's relatively-new dynamic-array-formula functionality (with comparable performance).

and IIRC, datatype conversion made through excel formatting options. change cell display to get decimal :) fun

I'm pretty sure that modifying a cell's number format never affects the underlying value.

maybe not the actual memory data, but AFAIK it does affect the behavior of other logical / arithmetic functions in strange ways

Okay, thanks. If this is correct... it's unsettling and not cool.

there are excel parsing libraries will treat the underlying data differently depending on how it is formatted.

operations people basically have to do workarounds for this all the time.

Not open source, but VBScript used to be embeddable in VB6 apps, I think VB.NET might have had something too?

Yes, you can host .NET runtime into another application.

https://learn.microsoft.com/en-us/dotnet/core/tutorials/netc...

Yeah but my confusion now comes from the fact that I don't think VB is even updated by MS anymore.

Kind of, it is still updated to keep being used in .NET latest, and at very least consume newer APIs, and profit from runtime improvements.

Much better position than VB 6.

Fair! I just assume its basically the slowest phasing out. It's a shame, VB6 was my first language, and I had strong hopes for VB .NET but having access to C# makes VB feel pointless, especially since it won that "language war" essentially.

I do hope one day Microsoft open sources VB6. I think it would be quite an interesting thing to see.

Not open source, but if you are ein Windows, youncnanuse the Windows Script Host via COM: https://learn.microsoft.com/en-us/previous-versions//a74hyyw...

Didn't they recently deprecate this?

https://nolongerset.com/vbscript-deprecation/

VBScript and VBA are unfortunately different languages in practice, at least when it comes to standard library.

Doesn't Libreoffice have an implementation of VBA?

As someone stuff using VBA at work this is really good. One niggle for me would be the lack of a section on VBA arrays. They're probably the most confusing things to use in VBA closely followed by error handling.

Hey look, proper documentation! Even has clear IP classification in front and revision history! How standards have fallen…

Can this trace its roots back to the spec BillG reviewed of lore?

https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...

Is the language spec for Visual Basic 6 available anywhere?

I don't think VB6 (or really any prior VB) had a real spec, the language was basically QBASIC stitched on a form editor for VB1 and extended over time to add more stuff and after some point could also be embedded in other programs (hence "Visual Basic for Applications").

AFAIK this spec isn't even for VB6, but for a "VB7" (i.e. VB6 with a bunch of changes) that never really got a standalone version and Microsoft made a spec for after the fact once they decided to attempt to make the file formats used in Office an open standard.

It is useful if you want to make a VB6 compatible parser but AFAIK those who attempted that had to "peek and poke" the real VB6 for various edge corners anyway.

QuickBasic, not QBasic.

They weren't the same, those that only experienced MS-DOS 5.0 QBasic keep mixing them up.

QBasic was a stripped down version of QuickBasic.

Not sure about you, talking in general.

Strictly speaking i don't think it was QuickBasic either (VB1 for DOS most likely was but IIRC there were minor language differences between the two), but in my message i didn't mean the exact product, just that it used an existing BASIC implementation they had with their take on making BASIC more Pascal-like. QBASIC is by far the most known implementation of that dialect.

(i just made a search and found an article about VB1's history and VB1 was indeed based on an existing BASIC engine they called "Embedded Basic")

Visual Basic clearly seems to have been aiming at QBasic/QuickBasic compatibility, in any case.

For example, the CALL keyword in QBasic is almost useless: It allows you to call procedures without a DECLARE statement, but DECLARE statements are automatically generated on save anyway.

In Visual Basic, even in version 1.0, it's completely useless because DECLARE statements are not required anymore, but both CALL and DECLARE are still in there in the language, presumably for compatibility.

I don't think so, or at least by VB5/6 they had moved on a long way. For instance VB6 compiled to native code rather than running as an interpreter. It could even create COM objects if you felt brave enough.

> It could even create COM objects if you felt brave enough.

Not just "brave enough" - but everyone, honestly. After VB4 and Windows 95, VB's raison d'etre was all about being a glue-language for anyone, regardless of ability level, to piece-together OLE/COM/ActiveX controls and components together onto a form/window surface and ship it the same day.

----

COM only requires bravery if you're lucky enough to be required to implement (or just consume), a COM service from C or a non-COM-blessed language. It is unfortunate that COM (honestly!) is a powerful platform feature built-in to Windows, but it's stagnated and permanently stuck in the year 1999 now - the lack of maintained documentation also makes it incredibly difficult to grok by newcomers. I'll bet there are more people in Gen Z who speak COBOL than feel comfortable around COM/COM+/DCOM.

COM has become iunknown ;)

And later extended with IInspectable.

COM is the main Windows API since Windows Longhorn .NET ideas were reintroduced as COM libraries in Windows Vista.

Yes, the tooling is still clunky, regardless it being the main way to expose Windows APIs nowadays.

With "i don't think so" you meant the part about "extended over time to add more stuff"? Even VB1 worked by compiling the statements to bytecode, changing that to emit machine language instead wasn't such a big leap that they'd need to make a new compiler. It was an important change (the perception of which was most likely also magnified by the new IDE UI) but it was still an evolution over VB4.

Everything has a spec. What do you mean?

It might not have had a written/formal spec, but Microsoft VB6 compiler itself is the spec in that case. I would assume that by VB6, however, something had been written down internal to MS.

I meant a written spec, at least that is what i assume one would mean when they ask for a language spec.

Years and years ago I wrote a basic VB6 -> JVM compiler. I could never find any spec other than the MSDN documentation, so it was basically trial and error to figure out the grammar. Found a bug or two in the VB6 IDE.

Just drop the parts about PtrSafe, LongPtr and LongLong, and it's the same.

Although not "official" by MS, perhaps the one from ANTLR's collection [0] is a good start (there are also other ANTLR VB6 grammars documented elsewhere). It does require knowing ANTLR's meta syntax, but it's not that far from (E)BNF.

[0] https://github.com/antlr/grammars-v4/tree/master/vb6

Wow there is a lot to VBA!

Reply on news.ycombinator.com