Serverless QBasic(psuter.net)
psuter.net
Serverless QBasic
https://psuter.net/2018/07/15/serverless-qbasic
39 comments
This is really interesting, thank you! I've been working the last couple of days on getting an old type-in game working and I had some vague thoughts about it being fun to somehow make it playable on the web. I'd have to convert it from Microsoft BASIC to the dialect BaCon uses, but that's definitely an option. Another option I've considered is to see about getting cbmbasic[0] running using a JS terminal emulator. And of course it might be a fun exercise to just convert them by hand to JS or what have you.
[0]: https://github.com/mist64/cbmbasic
[0]: https://github.com/mist64/cbmbasic
Happy that it could get the juices flowing :) The chosen implementation for your project certainly depends on what "vibe" and level of authenticity you're looking to achieve. I'm a huge fan of WebAssembly simply because the idea of writing web-native code in a language of my choosing makes the little computer scientist in me giddy.
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.
[0]: https://news.ycombinator.com/item?id=17487936
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.
[0]: https://news.ycombinator.com/item?id=17487936
It is my understanding that QB64 [1] compiles through C++, although I haven't tried it myself. They in theory support a superset of QBasic, and you could compile the C++ generated files using emscripten (again, in theory).
[1] https://en.wikipedia.org/wiki/QB64
[1] https://en.wikipedia.org/wiki/QB64
They are active on Twitter as well, https://twitter.com/QB64team.
Oh man, compiling to WebAssembly was exactly what I was thinking while reading the article. :)
It’s slow. All those layers of abstraction exact their toll on latency, even on today’s monster systems.
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.
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.
The Rust Evangelism Strike Force has nothing on the remnants of the once-mighty civilization from the Lost Continent of Amiga. "Oh, you poor benighted soul, how I pity you. Do you not know that the gods spoke in 68000 assembly? If you've never programmed the Copper via a DMA transfer in response to a raster interrupt, then my friend, you haven't truly begun to live."
I was firmly on the side of Atari ST, but I can't help but agree with you on this.
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.
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.
I have both, two Amigas and an ATARI Falcon 030. Do you know of any good hardware reference manuals for the ST?
The one that was the go-to manual back in the days was the Atari Compendium. I still have the book on my shelf.
I have seen digital versions (scans, I guess) floating around online. I don't know how complete they are.
There is still a demoscene for the Atari, although it's of course much smaller these days. You can find some pointers on our group's website: www.dhs.nu
I have seen digital versions (scans, I guess) floating around online. I don't know how complete they are.
There is still a demoscene for the Atari, although it's of course much smaller these days. You can find some pointers on our group's website: www.dhs.nu
The Rust Evangelism Strike Force has nothing on the remnants of the once-mighty civilization from the Lost Continent of Amiga.
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!
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!
Feels like a Pavlovian wound inflicted by the state of our industry. Find a little piece of nostalgia? Dockerize it!
Thanks for this fun article :)
I noticed your serverless function response time is between 2000 to 3000ms, I wonder why and it would be super interesting to have more details about time taken by each step of the process (python proxy / dosbox / qbasic / openwhisk)
Point of comparison, nodejs function executed on AWS Lambda: https://00demo-32387b.appdrag.com/api/Morse?txt=SOS-Test
Point of comparison, nodejs function executed on AWS Lambda: https://00demo-32387b.appdrag.com/api/Morse?txt=SOS-Test
Thank you!
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.
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.
> While Microsoft did have a compiler for the language, I couldn’t easily find a version of it online.
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...
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...
I see a few problems in the QuickBasic 4.5 (English) distribution available at antonis.de.
- 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.
- 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.
Thanks, this is great!
This is amazing! I have an old copy of GW Basic. Maybe it's worth an experiment to do the same with an even older interpreter for the fun of it!
Doing the same w/ GWBASIC ought to be pretty straightforward. It returned back to the OS via the "SYSTEM" statement. Back in the "day" before I had the QuickBASIC compiler I would invoke GWBASIC programs from batch files in a similar manner, pulling input from STDIN and outputting to STDOUT.
Awesome! Memories of "hacking" that gorillas-throwing-bananas game to mess with the physics, probably around 1995.
This is very cool. I've often wished I could return to my roots of simply programming, and not being a server admin and dba. Am I the only who wishes we could deploy things like BASIC applications to a runtime in the cloud and be done with all these layers of abstraction and incidental complexity?
I get the nostalgia, but even though I started with BASIC (Applesoft BASIC as an 8-year-old in 1988), I wouldn't want to go back there. Structured, object-oriented, event-driven, and functional programming are all truly useful. Trying to choose the modern programming language with the least incidental complexity is enough IMO.
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.
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.
A web-based Apple Basic emulator can be found at:
http://www.calormen.com/jsbasic/
I taught some intro programming to my kid using this.
http://www.calormen.com/jsbasic/
I taught some intro programming to my kid using this.
Source-code to draw a hamburger:
70 REM draw hamburger
80 HGR2:HCOLOR=5
100 for t = 1 to 50 step 0.01
140 x = Sin(Tan(t))
160 y = Cos(t)
180 xp = (x * 50) + 150
190 yp = (y * 50) + 100
200 HPLOT xp, yp TO xp, yp
300 next tYeah, I meant web applications with the ease of developing and running a basic program of old. Sorry that wasn't clear.
The suggestion to "use SYSTEM instead of END" is suspicious.
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.
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.
This is not true, system quits basic. In gwbasic this was unconditional since there was no ide, in qbasic it works if you used /run to start the program right away, otherwise system is equivalent to end and just drops you back into the ide.
It was definitely a little confusing, as there seems to be many ways of exiting. From the QBasic docs in the IDE:
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.
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 no arguments exited BASIC.
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.)
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.)
Looks like a fun project. :)
Describing a laptop from 1994 as “a netbook before there really was a net“ —- I don’t get.
Back then, they called it a subnotebook, and it was plenty useful offline. My Contura Aero (in 1994-95) had a 486 (SX I think, 25 or 33 MHz), 4 MB of RAM, and a ~170 MB hard drive. The 3.5" floppy drive was indeed connected via PCMCIA. Its primary purpose was taking notes in class and doing homework, but I also did some QBASIC and assembly programming on it.
My point is in 1994 we had web browsers, home ISPs and more. There was no “before the net” in 1994.
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