4 ms·
Wasn't QBasic the interpreter as opposed to QuickBasic the compiler?
by bencollver 1y ago
Wasn't QBasic the interpreter as opposed to QuickBasic the compiler?
- analog31 1y agoThis is what I recall too. QuickBasic was perhaps BASIC's answer to Turbo Pascal, a relatively lightweight but usable text based IDE. I knew some happy users.
- orionblastar 1y agohttps://winworldpc.com/product/quickbasic/45 https://winworldpc.com/product/quickbasic/45 for a look at QuickBASIC 4.5 abandonware; they also had QuickC and QuickPascal.
- pjmlp 1y agoNo, the answer was Quick Pascal, however Microsoft didn't really cared that much about it.
- deleted 1y ago[deleted]
- vunderba 1y agoIt's been a long time, but my impression was that QuickBASIC had an interpreter and the ability to compile. Then later on, Microsoft bundled a more limited version called QBasic with later versions of MS DOS which lacked the compiler. But all of them (QBasic, QuickBASIC, Microsoft PDS, and even Visual Basic for DOS which almost nobody remembers sadly) had the editor, interpretative execution, and built-in help.
- 90s_dev 1y agoI remember VB-DOS, and fondly too. It was magical. I think I used it even before VB3.
- agf 1y agoThis matches my memory. When I got my dad's old work computer with QuickBASIC on it, and I discovered the compiler, and could write programs other people could "just run", I felt like a real programmer for the first time.
- 90s_dev 1y agoYet you were even before that, the moment you made programs work at all.
- pjmlp 1y agoYes that was the case, by the time Visual Basic 5 came to be, its compiler was based on Visual C++ backend.
- deleted 1y ago[deleted]
- DCKP 1y agoAll this brings back fond memories of my first programming foray, an ASCII game in QBASIC from Mars and Back: Computer Programming Handbook by Andrew J. Read. So much fun, so much frustration.
- the_af 1y agoNo, QuickBasic was both an interpreter and a compiler. QBasic was just an interpreter.
- 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 agoWrong, 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 agoVB6 (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.