4 ms·

"Compiler". Even Visual Basic only compiled to p-code, which had to be interpreted at runtime. Not to fully native code. That's why it always ran slower than D

by klipt 1y ago

"Compiler". Even Visual Basic only compiled to p-code, which had to be interpreted at runtime. Not to fully native code. That's why it always ran slower than Delphi.

pjmlp 1y ago
Wrong, starting with with Visual Basic 5, a proper compiler was introduced based on Visual C++ backend, in addition to the P-Code interpreter. Additionally VB devs no longer needed to rely on C++ for ActiveX controls, aka OCX, the VBX replacement.
dspillett 1y ago
VB6 (and IIRC 5 too) could compile to native, as seen in the compile options: https://imgur.com/a/v0QcbBU https://imgur.com/a/v0QcbBU P-code was still offered as an option because some wanted the smaller output binary sizes, and the build process was faster⁰. Some incorrectly assume that the native option wasn't really fully compiled because the main supporting library (msvbvm60.dll) was still used¹, but this was for common library functions³ and the interpreter portion was not touched. There were unofficial tools that would statically link your exe with the relevant VB runtime (and certain other libraries) but the use of those was rare. ---- [0] Though I don't think the build speed matter was actually significant for many, if any, workflows, even on really slow kit. [1] Some didn't distribute it after a time, to reduce download sizes, as they were included with Windows so users already had them. Windows 7 (and maybe Vista?) included msvbvm60.dll and friends by default, and most XP and 98 installs² had it too as it came with Internet Explorer updates. [2] though there was a compatibility break at one point that meant you needed to recompile with VB6sp6 if you hadn't included a local copy in your apps directory [3] Much like many C programs don't have glibc statically linked into them, but work because it is practically ubiquitous on the systems they target.
- pjmlp 1y ago
  Having to depend on msvbvm60.dll was hardly any different than msvcrt.dll, but try to explain that to most folks.
lproven 1y ago
Both of these are incorrect. Both QuickBASIC and the BASIC Professional Development System compiled to full native DOS code, and could make standalone EXE files. VB finally gained this with VB 6 which could also make native EXE files.
the_af 1y ago
QuickBasic produced a DOS .EXE file. It didn't output p-code. You're confusing it with Visual Basic.
- lproven 1y ago
  You are correct, and VB 6, the final version, at last included a native-code compiler as well.

by klipt 1y ago

"Compiler". Even Visual Basic only compiled to p-code, which had to be interpreted at runtime. Not to fully native code. That's why it always ran slower than Delphi.

pjmlp 1y ago

Wrong, starting with with Visual Basic 5, a proper compiler was introduced based on Visual C++ backend, in addition to the P-Code interpreter. Additionally VB devs no longer needed to rely on C++ for ActiveX controls, aka OCX, the VBX replacement.

dspillett 1y ago

VB6 (and IIRC 5 too) could compile to native, as seen in the compile options: https://imgur.com/a/v0QcbBU https://imgur.com/a/v0QcbBU P-code was still offered as an option because some wanted the smaller output binary sizes, and the build process was faster⁰. Some incorrectly assume that the native option wasn't really fully compiled because the main supporting library (msvbvm60.dll) was still used¹, but this was for common library functions³ and the interpreter portion was not touched. There were unofficial tools that would statically link your exe with the relevant VB runtime (and certain other libraries) but the use of those was rare. ---- [0] Though I don't think the build speed matter was actually significant for many, if any, workflows, even on really slow kit. [1] Some didn't distribute it after a time, to reduce download sizes, as they were included with Windows so users already had them. Windows 7 (and maybe Vista?) included msvbvm60.dll and friends by default, and most XP and 98 installs² had it too as it came with Internet Explorer updates. [2] though there was a compatibility break at one point that meant you needed to recompile with VB6sp6 if you hadn't included a local copy in your apps directory [3] Much like many C programs don't have glibc statically linked into them, but work because it is practically ubiquitous on the systems they target.

pjmlp 1y ago
Having to depend on msvbvm60.dll was hardly any different than msvcrt.dll, but try to explain that to most folks.

lproven 1y ago

Both of these are incorrect. Both QuickBASIC and the BASIC Professional Development System compiled to full native DOS code, and could make standalone EXE files. VB finally gained this with VB 6 which could also make native EXE files.

the_af 1y ago

QuickBasic produced a DOS .EXE file. It didn't output p-code. You're confusing it with Visual Basic.

lproven 1y ago
You are correct, and VB 6, the final version, at last included a native-code compiler as well.