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.
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.
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.
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.
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.
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.
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.
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).
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.
39 comments
[ 3.0 ms ] story [ 94.3 ms ] threadAFAIK 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.
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.
(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")
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.
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.
Yes, the tooling is still clunky, regardless it being the main way to expose Windows APIs nowadays.
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.
[0] https://github.com/antlr/grammars-v4/tree/master/vb6
https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
- 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
operations people basically have to do workarounds for this all the time.
https://learn.microsoft.com/en-us/dotnet/core/tutorials/netc...
Much better position than VB 6.
I do hope one day Microsoft open sources VB6. I think it would be quite an interesting thing to see.
https://nolongerset.com/vbscript-deprecation/