On a related note (of using BASIC where it doesn't belong), I hacked together a method to convert BASIC code to WebAssembly using BaCon[0], a BASIC-to-C converter, and Emscripten to take the resulting C output and generate some wasm.[1] Much like the linked article, this is a fun diversion to entertain the idea of using BASIC where the language authors couldn't possibly have imagined it. Perhaps I'll get around to actually making a "real" project out of it sometime...
[0]: http://www.basic-converter.org/
[1]: https://github.com/matthewwiese/basic-to-c-wasm-example
That's not to mention the wealth of existing code with potential to be ported to this universal medium; for example, a project porting vim to WebAssembly was posted to HN just over a week ago[0] which reignited my interest in pursuing this avenue further.
Reading the essay, my heart goes out to the author: he missed all those wonderful years in the ‘80’s and the early ‘90’s cracking protections, swapping, coding intros, watching demos and competing on the Commodore64, Commodore Amiga and the ATARI ST. He missed out on all the wonderful memories and all the action. I’m saddened by it. He started out on an obscure platform and then switched immediately to a drab, boring, soulless PC bucket, never to experience the joy of the Scene.
For me writing software in BASIC under MS-DOS and later on Windows®️ was an afterthought, since I had already been proficient in MC68000 and MOS 6502 intro coding on Amiga and Commodore64. It was easy to do since I stumbled upon the complete, official reference manual on BASIC 3.0 from Microsoft and I already knew BASIC from learning it on the Commodore PLUS/4. The only piece of software I wrote was an ASCII survey points file to DXF converter which I then ported to VisualBASIC 2.0, and that because I also had the full AutoCAD book set which included full DXF format specification. It cut down our work from several hours to a few seconds, but BASIC on the PC had always been an afterthought for me, something I knew but never used much, or something to whip up a quick utility in and run it from a batch file wrapper.
On the Atari side:
Switching screen refresh times in the middle of the line in order trick the graphics chip to not draw the border so you can fill the entire screen with graphics is something every developer should have done, the Amiga with its fancy copper didn't need this.
And that is good so, for it means that there are still hidden places on this world where the chaos and evil that is Rust hasn’t reached. May it stay hidden and unsullied by the Darkness, and may the Rust evangelism strike force never spread their foul language there!
Point of comparison, nodejs function executed on AWS Lambda: https://00demo-32387b.appdrag.com/api/Morse?txt=SOS-Test
On a "warm" invocation, almost all the time goes into DOSBox + QBasic.
Not precise measurements but: on my MacBook Pro, running the QBasic interpreter from within DOSBox consistently takes about 1.5 seconds & running DOSBox + QBasic from the shell in "headless" mode takes about 2.4 seconds.
OpenWhisk also gives me the logs of the invocations, which include debug lines produced by DOSBox, and from the timestamps in those I can tell that invocations do typically spend >2s running DOSBox.
I have archived the QuickBASIC 4.5 compiler here: https://github.com/susam/dosage/tree/master/langs/qb45
The above archive is obtained from here: https://www.qbasic.net/en/qbasic-downloads/compiler/qbasic-c...
- The BRUN45.EXE file in QB_4_5_E.ZIP is the German version one whereas the other files in this ZIP are the English version ones.
- The original directory layout of QuickBasic 4.5 (INC/, HLP/, LIB/) is missing although all the important content from those directories are preserved in the top-level directory.
- The content of the INC/EXAMPLES/ directory is missing too.
The original distribution is much better preserved at the www.qbasic.net URL I shared earlier. It also contains the English version of QBasic 1.1 interpreter.
Furthermore, the UI facilities that early microcomputer BASICs provided would not be acceptable today. The graphics of the Apple II or QBASIC might be cool for a retro game, but you wouldn't want to develop a real application that way. For one thing, such applications were inaccessible to blind users with the primitive screen readers that existed back then, and today's screen readers would do no better. And a text UI with PRINT and INPUT would be accessible but even more retro. So even if you wrote an app in BASIC and deployed it to a cloud platform, you'd somehow have to use a modern platform like the Web for your UI. Unless, of course, you want to develop a retro game, and that might indeed be a fun side project.
http://www.calormen.com/jsbasic/
I taught some intro programming to my kid using this.
SYSTEM spawns the system shell as a sub-process. If one would EXIT from the spawned command.com/cmd.exe, QBASIC would pop up back. I think a user of programs written in this way would find themselves surprised.
END: Ends a program, procedure, block, or user-defined data type. [...] If no argument is supplied, END ends the program and closes all files.
STOP: Halts a program.
SYSTEM: Closes all open files and returns control to the operating system.
You may be thinking of:
SHELL: Suspends execution of a Basic program to run a DOS command or batch file.
SYSTEM with a string argument on some Microsoft BASICs spawned a shell that ran the command in the argument. On others, the SHELL command did this. (iirc mbasic on xenix used SHELL, GWbasic used SYSTEM with an argument.)
