4 ms·

Is the language spec for Visual Basic 6 available anywhere?

badsectoracula 3y ago
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.
- pjmlp 3y ago
  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.
  - badsectoracula 3y ago
    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")
    - ptx 3y ago
      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.
- tonyedgecombe 3y ago
  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.
  - DaiPlusPlus 3y ago
    > 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.
    - owlstuffing 3y ago
      COM has become iunknown ;)
      - pjmlp 3y ago
        And later extended with IInspectable.
    - pjmlp 3y ago
      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.
  - badsectoracula 3y ago
    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.
- deaddodo 3y ago
  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.
  - badsectoracula 3y ago
    I meant a written spec, at least that is what i assume one would mean when they ask for a language spec.
secondcoming 3y ago
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.
fafalone 3y ago
Just drop the parts about PtrSafe, LongPtr and LongLong, and it's the same.
signaru 3y ago
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 https://github.com/antlr/grammars-v4/tree/master/vb6

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.

pjmlp 3y ago
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.
- badsectoracula 3y ago
  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")
  - ptx 3y ago
    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.
tonyedgecombe 3y ago
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.
- DaiPlusPlus 3y ago
  > 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.
  - owlstuffing 3y ago
    COM has become iunknown ;)
    - pjmlp 3y ago
      And later extended with IInspectable.
  - pjmlp 3y ago
    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.
- badsectoracula 3y ago
  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.
deaddodo 3y ago
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.
- badsectoracula 3y ago
  I meant a written spec, at least that is what i assume one would mean when they ask for a language spec.

secondcoming 3y ago

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.

fafalone 3y ago

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

signaru 3y ago

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 https://github.com/antlr/grammars-v4/tree/master/vb6