[pjmlp]

> The ecosystem was more coherent. VB wasn't usable for many advanced tasks so VB devs relied heavily on components written in C++ (OCX controls)

Until VB 6, which introduced AOT compilation based on VC++ backend, and creation of OCX in VB itself.

To this day, one of the easiest way to do COM on Windows, even better than .NET Framework (.NET Core made it harder, yet another thing that Framework does better).

[mike_hearn]

I thought VB6 used p-code embedded into the EXE? I don't think compiling VB6 to machine code would have been easy.

[pjmlp]

Nope, that is how VB worked until version 6.

In version 6, you could chose what compilation model, classical (p-code) or the new AOT backend.

Compiling BASIC to machine code is how it was born after all, the interpreters came to be in 8 bit machines, due to their hardware constraints.

Besides, Microsoft already had similar experience with a dual compilation model in Quick BASIC.

And not to leave this being my opinion only,

"Microsoft Visual Basic allows you to compile your applications to fast, efficient native code, using the same optimizing back-end compiler technology as Microsoft Visual C++. Native code compilation provides several options for optimizing and debugging that aren't available with p-code. These options are traditionally called "switches," because each option can be turned on or off."

https://learn.microsoft.com/en-us/previous-versions/visualst...

[badsectoracula]

It allowed for both, the default being pcode (IIRC because it was more compact) but it could also do native code. The feature was introduced in VB5.

Note that it still required the VB runtime either way.