2 ms·
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 ev
by 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 agoCOM has become iunknown ;)
- pjmlp 3y agoAnd later extended with IInspectable.
- pjmlp 3y agoCOM 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 agoWith "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.