Visual BASIC is emulated via Jabaco and converted to Java Runtine files. http://www.jabaco.org/ but it hasn't been maintained in a while either. It does VB 6.0 but misses ADO and other libraries needed for Data access, you have to use Java based ones instead with BASIC syntax.
http://www.qb64.net/ <-- IIRC that's supposed to be a fully backwards compatible + a bunch of modern enhancements to build QuickBasic/QBasic on modern platforms.
UPDATE: .... And, I should read the link before commenting, because QB64 is mentioned right there nearly above the fold.
This is an interesting view into Qbasic's longevity; your posts are from 2007, long past its release date of 1992.
The suite itself predates popular use of the Web by a handful of years and yet the community's size seems to have peaked long after its release. I've been able to trace an active Qbasic community all the way to 2011.
It was also a pure accident that I started programming at all. This was 2007, I had inherited an old Windows 95 computer that was recycled from my Mom's law office where she was a paralegal. She let me rig it up in my bedroom as a teenager and I somehow discovered it came with QBasic 1.1 installed on it. I didn't know anyone who coded or programmed, and I learned everything from browsing around Pete's. I later discovered Python from the same forum, and well- I'm still coding 12 years later.
How I got started: the "big kids" at school showed me how to play Qbasic Nibbles on our school computers, circa 1999-2000. I remember the first things I did was try to add "cheat codes" to Nibbles, and then use PRINT/INPUT to make a joke DOS prompt.
About three years later I get a hand-me-down Windows 95 machine with Qbasic on it, and I set out to make my own "operating system". This was actually a pretty popular thing to do at the time...here's an entire website full of 'em, where I published my own MS-DOS GUI as a teenager: http://qbasicgui.datacomponents.net/
Today, I do very well as a senior developer wearing multiple programming hats at my company and I'm close to cashing in some of that stock to develop my own video game. It all started with Qbasic.
Yes! A lot of us got our start with QB. After all, we're all alike. I was immediately off to the races when I discovered Excel VBA is 98% QB. Promotions and raises soon followed, from automating massive amounts of work. Now I am very senior in the field. (intentionally vague)
I know this is old news now, but I never knew this stuff existed! I wanted to make something similar back in the day. You've given me a rabbit hole of nostalgia to peruse, thanks :)
There's never been anything quite like Qbasic. Bundled with the OS, providing clear and relatively foolproof syntax, with an ability to get graphics onscreen extremely quickly. Plus, an amazing and decently large community of amateur game makers who grow up to be the next generation of professional developers.
I struggle to conceptualise a modern form of it - something that's perhaps a cross of Hypercard, Visual Basic, and Unity.
Microsoft help systems were great back then. Which was good, as there was little online documentation, and what was available was expensive to access with per-minute dial-up fees
I remember a version of MS C in the late 80s coming with 5,500 pages of printed documentation! And it was easy to find what you needed
i agree. imagine my disappointment upon installing Redhat Linux 5.2 in 1998 (from a CD-ROM that came bundled with a magazine!) and naively trying the man pages for documentation.
Sadly today with (internet) online documentation things are still not as good - even if often there is more information, it is scattered all over the place, often repeating (parts of) itself and slow to find and access. The main reason why i prefer to have a WIN32.HLP file from (i think) some Borland product whenever i need some Win32 function than search Google for it for MS Docs (the test is 99.9% of the cases the same anyway). Also why i have Zeal[0] installed with the docs of a few things i use and i download offline copies of whatever specs and documentation i can find for other things.
But in terms of help systems, i think CHM was the peak (in terms of functionality - the HTML-based content is a bit of unnecessary overhead and something like HLP's hypertext should have been good enough, but Microsoft wanted to shove IE4 everywhere so they can claim it was an integral part of Windows 98 back then).
It really was fantastic. I taught myself QBasic out of the help screen when I was a teen. I spent many afternoons flicking through the extensive documentation and finding functions with interesting sounding names to read about and try as I programmed little games for myself.
Glad I'm not the only one feeling this pain! My graphics needs are minimal (usually amounting to a dead-simple visualization of a musical score I'm working on), but the complexity of coding any such feature is beyond my self-taught-on-LOGO-and-QBasic skills.
Modern graphical programming has nothing to do with setting pixels on a framebuffer the way you would in typical BASIC or LOGO implementations. You're essentially dealing purely with "surfaces" that work pretty much like glorified sprites (although supporting all sorts of 3D-like transforms), and then "compositing" the final result in hardware. This is why modern accelerated graphics can cheaply support very impressive visual effects, but has a bit more trouble achieving the inherent "pixel-perfect" effects that you got with purely software-based systems.
It was approachable. First language I learned was Turbo Pascal, and it inspired me to learn more via QBasic on an old 286 I had been given. (1995 I think)
GW-BASIC (no built-in help, incompatible with most library books, no real editor: hard for a kid to teach themselves from nothing)
-> QBasic (Help! Graphics programs that crashed didn't leave you in graphics mode! Proper editor!)
-> QuickBasic (bigger programs, compile to .exe)
-> Turbo Pascal (help, compile-time errors, programs ran fast in comparison, proper modular code, good editor (great in 6.0), advanced graphics (for the time) totally within reach, and that's where a lot of high-school lunch hours went).
Once Windows started to catch on, Visual Basic and Delphi (both had integrated help), then C++ (though I'd done some of that in DOS too, with Turbo C++).
Integrated help systems were almost essential before the internet, and Microsoft and Borland did them well.
Really cool thing I remember about Turbo Pascal was that you could drop in x86 Assembly right in your Turbo Pascal code and the compiler would take care of it. If you wanted to write a function with better performance you could just use assembly.
I don't code with a debugger, and I know a ton of people who don't either. I think people like me just rely on a REPL, which is enough. I find most debuggers to be intrusive and flow-breaking.
I do agree that a lack of both, however, is crazy to think about. Yet I hired a developer not long ago who did basically that while shopping JCL Cobol for a student loans company.
printf-style debugging counts as an interactive debugger? Then I guess... yes. I just took that phrase as being an actual full-fledged debugger, not irresponsible printing to console (which is what I do).
No, I’m saying that in those cases you _should_ be using a debugger, because it’s just so much easier and more powerful. My point being, why do so many people have a day to day workflow inferior to what was available for free decades ago to kids making gorillas throw bananas at each other?
A debugger is helpful if you don't know which value you want and want to go exploring. Print statements are helpful if you want the value at thousands of different points in time - you don't know when you want the value - and want to fish it out later.
In that situation you’d generally use conditional breakpoints. If you’re just scrubbing up and down in thousands of lines of output looking for something fishy, that doesn’t seem very productive. I’m also on board with generative testing to find these sorts of edge cases, if relevant.
It's the "how did I get here?" question: you have a clear logfile marker for "something went wrong", such as a stack trace, and then scroll back upwards to determine what went wrong. Can even be a negative, which is incredibly hard to do with breakpoints: "I should be seeing line X after Y or before Z, but it's not there"
Can also be a ward against the insecurity of unknown unknowns - where there's a lot of moving parts and the problem isn't well isolated (we'd all like it to be, but maybe previous developers didn't design the system like that) or the OS or one of your libraries is betraying you.
Sure, I’m not really saying every problem in software can be solved with a debugger. But not being able to easily narrow down which part of a system is breaking an invariant shouldn’t be an everyday occurrence. Obviously shit happens (or happened in the past) and you’ve sometimes gotta do what you gotta do though.
> But not being able to easily narrow down which part of a system is breaking an invariant shouldn’t be an everyday occurrence
I think there's a kind of reverse Amdahl's law at work here. Situations where there is a nice clean crash into the debugger that tells you what's going on are easy - so they don't take up much time. Situations where that doesn't work take much longer - maybe the problem doesn't replicate when you're using the debugger. And there have been situations where simply doing the data-gathering to establish that a bug was real consumes weeks. My own personal one of those was missed touchscreen events; because they were so infrequent we eventually had to set up a robot to press the screen 10,000 times, resulting in 9,999 touch events, and record a huge amount of data up and down the stack in order to work out what had happened.
I've found most "conditions" in conditional breakpoints to be very limiting, especially if i want to query objects and the debugger cannot do that. Usually i start with printf and then i just modify the code with something like "if (condition) __debugbreak();" (or the langage equivalent).
Oh, I probably should be, yes. But I won't, because I don't like them and never really have. I realize this is probably less productive, but at least I'm self-aware about it.
And I don't think it's heresy to say that many people just don't like the current crop of debuggers out there, especially when you write in dynamic (and weakly typed) languages. Which is another bunch of bananas, but sometimes we don't get to pick what code we write in, especially in my industry.
Oh I totally agree about the causes, I’m more bemoaning the tooling. I too work in languages sometimes where it’s really hard, which is why I chuckle at what 10-year-old me would think about all the complexity.
I don’t code with a debugger either. If I need to use a debugger to figure out the logic I just wrote then I have failed to make it clean enough to understand.
Well, shit happens, and you may need to receive inputs that are out of your control, or use libraries that are less then perfect and you need to use intermediate results. In those cases a debugger (or even just strategic prints) can be a godsend.
What if you inherited someone else's code? Are you going to change all the libraries because you don't like them? Or even if they use good libraries, how are you going to unravel complex pieces of code?
What I'm trying to say is, sometimes you need all the help you can get. And even an awful debugger is better than doing it in your head.
Processing was the closest thing that I found. That was my first and simplest post-QBasic programming, and it served as a great jumping-off point into a real career in the industry.
I still reach for p5.js when I need to throw up a quick visual demo of something.
Meh. BASIC-like languages are "clear and relatively foolproof", but not because of their syntax. The genuinely "clear" elements that they do have, such as the use of numeric labels, turn out to be poorly scalable, and the syntax itself also accretes all sorts of warts as it's extended beyond trivial functionality. Mostly, they are just simple enough that it is feasible to grok and fully internalize the functioning of the system as a whole, even for novices.
"Getting graphics onscreen quickly" came with the territory on MS-DOS systems. The basic hardware functionality was standardized and there was no multi-processing to step on your toes, so just set the graphics mode you want, call some pre-made drawing routines, and you're set.
The actual nice thing about those packages was the straightforward support they provided for the mostly gaming-oriented hardware features in those machines (particularly the Amiga). In this way, they were close precursors to present-day game engines like Godot. And this also creates a conundrum for anyone wanting to bring the originals back, of course - do you reimplement their actual features, even if this means basically emulating a legacy platform?
> There's never been anything quite like Qbasic. Bundled with the OS
On home computers throughout the 1980s, BASIC WAS the OS.
I also found it bizarre, how you can't even use modern computers costing hundreds of dollars as a simple calculator if the OS can't boot up.
I wish Apple would bundle something like iOS Swift Playgrounds with macOS, considering they already include Script Editor, Automator, Pages, Numbers, GarageBand etc.
> There's never been anything quite like Qbasic. Bundled with the OS, providing clear and relatively foolproof syntax, with an ability to get graphics onscreen extremely quickly. Plus, an amazing and decently large community of amateur game makers who grow up to be the next generation of professional developers.
The C=64, Atari ST, etc. all had decent BASICs and large communities.
It’s interesting that QBasic was thought of as a beginners or gaming language
In the early 90s, I worked on a bond trading floor in London, and we used QBasic for production systems. It was quite fun to work with, and pretty powerful with the right libraries.
This was all in Dos as it was before Windows 3 was released, and getting everything to work in 640k was fun (I recall there was a system to page in and out different parts of the app, but my memory may be faulty on this part)
Part of the appeal Qbasic had to me as a kid, was that I read that it was occasionally used in a professional capacity. So this easy-to-learn, easy-to-use language had the added cool-factor of being "real stuff". I don't think something like Gamemaker or Scratch would've had the same appeal - they'd just feel like baby's toys to me, whereas with something like Qbasic you knew you were actually doing "real" programming.
It was certainly real stuff - less than 5 years later I was part of the team that shipped Windows 95 (but I was a C programmer before QuickBasic, so that helped)
The QB 4.5 / PDS 7.1 compilers (linked on that site) were actually decent. Coupled with some of the ASM libraries available at the time there were crazy possibilities. I had a background/TSR file transfer utility in 1989(?) written in QB 4.5 and assembler for the fun stuff. (Never commercialized, the boss said "the computer still has to be on to receive things? that's useless")
There were numerous vertical market applications developed in QB/ PDS; things we'd call CRM today all the way to "estimate how many passes this scraper will take to build an earth dam of this size and shape" tools.
Microsoft forsaking that toolchain in favor of Windows / Visual Basic put a lot of those shops out of business.
Back in the late '90's there was the All BASIC Code (ABC) repository, which was a large collection of the best Basic code at the time. Some of my code made it there. Found this copy here: https://github.com/qb40/abcarchive
I used to be active on the QB FIDOnet forums in the mid-90's until many of the BBSs shut down. It was my favorite language during my teen years!
I'm reading Anders E. Zonst's "Understanding the FFT" second edition, and the programs were originally in GW-BASIC.
I have since installed qb64 and PCBASIC, and find the book really amazing; consequently I find the language superior for simple exposition - there's an insane amount of positive things you can say about taking a supposedly complex subject and breaking it down with a language that is that simple - if you truly understand a thing, you can implement it in a language as simple as BASIC in a clear way, taking the mystery out of it.
How hard can it be if it you can implement it on something with a Z80, right?
Brilliant, and odd timing that this is on HN right now.
There are a few rough edges in old BASICs(and they have been smoothed out in pretty much every one that's shipped since 1990 or so) but the practical truth is, to implement most code in a readable form, you don't need a great deal of expressiveness, syntactical sugar, or structured flow control, but you do need a few common data types and features to work with them, and even vintage BASIC does that much.
This is what people mean when they say that languages haven't progressed that much. There are places where they have(e.g. dynamic memory allocation features really do matter to large-enough, featureful-enough programs) but almost all the features can be dispensed with for the base case of solving one problem well. The tooling and ecosystem matter a great deal more since they make the difference between having a finished solution in hand and having to fight to get something built and deployed. I/O and protocol compatibility are major sticking points everywhere.
I'm another one of those who learned their ropes in QBasic, circa 2001.
A substitute teacher told us about logo and my 13-year old mind thought you just need to type the commands on the windows desktop to make it work. Imagine my disappointment when it didn't work.
So one day we're at my dad's friend home. Their son puts a floppy in, starts a weird blue application, loads a file called GORILLA.BAS and starts the program. Then I understand what's going on: that's something you can write your programs in! Copy that floppy and give it to me!
One of my school books had a basic BASIC tutorial so I started typing useless code.
Then I discovered RapidQ which was superficially like VisualBasic but didn't cost a dime (at least, that's how I remember it...). So I could make GUIs using a drag&drop interface.
I used to visit the QBasic.com website around the early 2000s, it was also a trove of information. Was fun to dissect snippets that did raycasting or 3D wireframe animations.
First of all, Thanks. Hats off! Learning BASIC made me a better human. I learned x86 ASM, Win32API all thanks to freeBASIC and VB6. I think the best decision I've made in young life (13-14 years old) is learning BASIC, which made me the developer today.
Ah man, QBasic makes me feel nostalgic! My first experiences of programming were with ZX Spectrum and BBC Micro BASIC when I was 5 or 6 or so but that was just simple IF this PRINT that type stuff, or copying listings from books. QBasic was where I first started realising you could do some really cool things with the combination of your brain and programming!
I remember a teacher at school used to let us use the computers at lunch to play with QBasic and being very proud of working out how to draw a BMP file (in the days before we had Internet access)... and then a pupil in the year above blowing that completely away with a demo he’d written with pseudo-3D graphics and everything. He later got expelled for writing some kind of boot sector virus and installing it on the school computers. Wonder what he is up to now!
I was introduced to QBasic by a friend in the mid/late 90's and spent a great deal of time on a community called NeoZones. The site allowed people to showcase their work, tutorials for learning, forums for talking with everyone else -- there was always something to dig into and such fun. I've never experienced a developer/programming community like that since. I hope there are still communities like that out there and would love to find some to be part of again.
At some point there was a fork of NeoZones into NeoBasic. Last I checked, NeoBasic.net still had forums, but only long time regulars barely post. It looks down today, sadly.
I was using QuickBasic before there was a QBasic. (QuickBasic compiled to an executable for those who are unfamiliar with it.) Made some money with it as a teen programmer. I built a menuing system modeled after Automenu (by Magee Enterprises), but with an easier to follow config format and more flexibility. It ended up being popular enough to sell in my little corner of the DOS universe. Sold it on floppy disk at a local computer store.
I spent a lot of time with Pete on ICQ in the late 90s. He really taught me a lot of basics (heh) about programming back then, and his community was great. Many regulars from his site and NeoZones/Neobasic are still in contact with each other, and it's crazy seeing what some people do now, like release TurboGrafx games.
QBasic was probably the first language I wrote something in from start to finish. It was an attempt at a clone of Deflektor [0].
Before that, I never really got anywhere on the Sinclair ZX Spectrum or Commodore 64, though I still hope to go back in an emulator and make up for that someday.
82 comments
[ 2.8 ms ] story [ 166 ms ] threadhttps://www.freebasic.net/
Visual BASIC is emulated via Jabaco and converted to Java Runtine files. http://www.jabaco.org/ but it hasn't been maintained in a while either. It does VB 6.0 but misses ADO and other libraries needed for Data access, you have to use Java based ones instead with BASIC syntax.
UPDATE: .... And, I should read the link before commenting, because QB64 is mentioned right there nearly above the fold.
https://en.wikipedia.org/wiki/Gambas
http://www.basic-converter.org/
I recovered it on some old hard drives a few years ago and backed it up here: https://github.com/vesche/snippets/tree/master/qbasic
Loved these forums as a young kid with nothing more than a windows 95 computer and a QBASIC interpreter.
The suite itself predates popular use of the Web by a handful of years and yet the community's size seems to have peaked long after its release. I've been able to trace an active Qbasic community all the way to 2011.
About three years later I get a hand-me-down Windows 95 machine with Qbasic on it, and I set out to make my own "operating system". This was actually a pretty popular thing to do at the time...here's an entire website full of 'em, where I published my own MS-DOS GUI as a teenager: http://qbasicgui.datacomponents.net/
Today, I do very well as a senior developer wearing multiple programming hats at my company and I'm close to cashing in some of that stock to develop my own video game. It all started with Qbasic.
I'm a senior cyber security engineer and also a polygot :) Video games sound more fun, I still make some in my free time.
I struggle to conceptualise a modern form of it - something that's perhaps a cross of Hypercard, Visual Basic, and Unity.
I remember a version of MS C in the late 80s coming with 5,500 pages of printed documentation! And it was easy to find what you needed
Sadly today with (internet) online documentation things are still not as good - even if often there is more information, it is scattered all over the place, often repeating (parts of) itself and slow to find and access. The main reason why i prefer to have a WIN32.HLP file from (i think) some Borland product whenever i need some Win32 function than search Google for it for MS Docs (the test is 99.9% of the cases the same anyway). Also why i have Zeal[0] installed with the docs of a few things i use and i download offline copies of whatever specs and documentation i can find for other things.
But in terms of help systems, i think CHM was the peak (in terms of functionality - the HTML-based content is a bit of unnecessary overhead and something like HLP's hypertext should have been good enough, but Microsoft wanted to shove IE4 everywhere so they can claim it was an integral part of Windows 98 back then).
[0] https://zealdocs.org/
GW-BASIC (no built-in help, incompatible with most library books, no real editor: hard for a kid to teach themselves from nothing)
-> QBasic (Help! Graphics programs that crashed didn't leave you in graphics mode! Proper editor!)
-> QuickBasic (bigger programs, compile to .exe)
-> Turbo Pascal (help, compile-time errors, programs ran fast in comparison, proper modular code, good editor (great in 6.0), advanced graphics (for the time) totally within reach, and that's where a lot of high-school lunch hours went).
Once Windows started to catch on, Visual Basic and Delphi (both had integrated help), then C++ (though I'd done some of that in DOS too, with Turbo C++).
Integrated help systems were almost essential before the internet, and Microsoft and Borland did them well.
I do agree that a lack of both, however, is crazy to think about. Yet I hired a developer not long ago who did basically that while shopping JCL Cobol for a student loans company.
Can also be a ward against the insecurity of unknown unknowns - where there's a lot of moving parts and the problem isn't well isolated (we'd all like it to be, but maybe previous developers didn't design the system like that) or the OS or one of your libraries is betraying you.
I think there's a kind of reverse Amdahl's law at work here. Situations where there is a nice clean crash into the debugger that tells you what's going on are easy - so they don't take up much time. Situations where that doesn't work take much longer - maybe the problem doesn't replicate when you're using the debugger. And there have been situations where simply doing the data-gathering to establish that a bug was real consumes weeks. My own personal one of those was missed touchscreen events; because they were so infrequent we eventually had to set up a robot to press the screen 10,000 times, resulting in 9,999 touch events, and record a huge amount of data up and down the stack in order to work out what had happened.
And I don't think it's heresy to say that many people just don't like the current crop of debuggers out there, especially when you write in dynamic (and weakly typed) languages. Which is another bunch of bananas, but sometimes we don't get to pick what code we write in, especially in my industry.
What I'm trying to say is, sometimes you need all the help you can get. And even an awful debugger is better than doing it in your head.
For third party libs I work with the vendor to unshit their shit. Or I switch, yes.
I write code that has to run out in BFE for 5-10 years. I can’t be sloppy about it.
I still reach for p5.js when I need to throw up a quick visual demo of something.
Meh. BASIC-like languages are "clear and relatively foolproof", but not because of their syntax. The genuinely "clear" elements that they do have, such as the use of numeric labels, turn out to be poorly scalable, and the syntax itself also accretes all sorts of warts as it's extended beyond trivial functionality. Mostly, they are just simple enough that it is feasible to grok and fully internalize the functioning of the system as a whole, even for novices.
"Getting graphics onscreen quickly" came with the territory on MS-DOS systems. The basic hardware functionality was standardized and there was no multi-processing to step on your toes, so just set the graphics mode you want, call some pre-made drawing routines, and you're set.
The author of AMOS / STOS is bringing back and he did an interview here.
https://www.youtube.com/watch?v=Hs-QOu8EAWY
He seems to have gone the browser route which I am not keen on though.
There needs to be something that is simple like QBasic where you can just start programming and have a crack at doing something fun.
On home computers throughout the 1980s, BASIC WAS the OS.
I also found it bizarre, how you can't even use modern computers costing hundreds of dollars as a simple calculator if the OS can't boot up.
I wish Apple would bundle something like iOS Swift Playgrounds with macOS, considering they already include Script Editor, Automator, Pages, Numbers, GarageBand etc.
The C=64, Atari ST, etc. all had decent BASICs and large communities.
In the early 90s, I worked on a bond trading floor in London, and we used QBasic for production systems. It was quite fun to work with, and pretty powerful with the right libraries.
This was all in Dos as it was before Windows 3 was released, and getting everything to work in 640k was fun (I recall there was a system to page in and out different parts of the app, but my memory may be faulty on this part)
There were numerous vertical market applications developed in QB/ PDS; things we'd call CRM today all the way to "estimate how many passes this scraper will take to build an earth dam of this size and shape" tools.
Microsoft forsaking that toolchain in favor of Windows / Visual Basic put a lot of those shops out of business.
I used to be active on the QB FIDOnet forums in the mid-90's until many of the BBSs shut down. It was my favorite language during my teen years!
I have since installed qb64 and PCBASIC, and find the book really amazing; consequently I find the language superior for simple exposition - there's an insane amount of positive things you can say about taking a supposedly complex subject and breaking it down with a language that is that simple - if you truly understand a thing, you can implement it in a language as simple as BASIC in a clear way, taking the mystery out of it.
How hard can it be if it you can implement it on something with a Z80, right?
Brilliant, and odd timing that this is on HN right now.
This is what people mean when they say that languages haven't progressed that much. There are places where they have(e.g. dynamic memory allocation features really do matter to large-enough, featureful-enough programs) but almost all the features can be dispensed with for the base case of solving one problem well. The tooling and ecosystem matter a great deal more since they make the difference between having a finished solution in hand and having to fight to get something built and deployed. I/O and protocol compatibility are major sticking points everywhere.
I'm another one of those who learned their ropes in QBasic, circa 2001.
A substitute teacher told us about logo and my 13-year old mind thought you just need to type the commands on the windows desktop to make it work. Imagine my disappointment when it didn't work.
So one day we're at my dad's friend home. Their son puts a floppy in, starts a weird blue application, loads a file called GORILLA.BAS and starts the program. Then I understand what's going on: that's something you can write your programs in! Copy that floppy and give it to me!
One of my school books had a basic BASIC tutorial so I started typing useless code.
Then I discovered RapidQ which was superficially like VisualBasic but didn't cost a dime (at least, that's how I remember it...). So I could make GUIs using a drag&drop interface.
Good times :)
Interestingly, it seems that the website was re-purposed briefly in 2002: http://web.archive.org/web/20020524053704/http://qbasic.com/
...but in 2003, it returned to its regularly scheduled content: http://web.archive.org/web/20030207131457/http://www.qbasic....
I remember a teacher at school used to let us use the computers at lunch to play with QBasic and being very proud of working out how to draw a BMP file (in the days before we had Internet access)... and then a pupil in the year above blowing that completely away with a demo he’d written with pseudo-3D graphics and everything. He later got expelled for writing some kind of boot sector virus and installing it on the school computers. Wonder what he is up to now!
Before that, I never really got anywhere on the Sinclair ZX Spectrum or Commodore 64, though I still hope to go back in an emulator and make up for that someday.
[0] https://www.youtube.com/watch?v=mzA8NdXEB2M