Running Old Programs In The Browser

I did my first programming in Applesoft BASIC on the Apple IIc, and then I did quite a bit in middle school and early high school in QBasic on a 486 machine.

I’ve been in a bit of an archival kick lately. I recently started a small project of getting some data off of my Apple IIc disks, which is going well. I thought: maybe there is a way to get my old QBasic programs running as well.

QBasic ran under MS-DOS, the command-line interface of pre-Windows and early Windows computers. You can see a more modern version by typing cmd at the Windows program. I wanted to get a way that I could look at my old programs and to preserve and distribute them to others.

I looked around for a QBasic emulator, and except for the well-known and battle-tested DOSBox DOS emulator, could only find a partially-completed QBasic interpreter written in JavaScript. It didn’t have graphics mode, and many of the programs that I wrote used this. has a huge collection of DOS games. This is great for preserving old software. You can even play old games, although any game saves won’t persist between page reloads1. The DOS collection runs on em-dosbox, which compiles the DOSBox DOS emulator from C++ to Javascript using emscripten. Fortunately, all of this is open source.

I was able to get a copy of the QBasic executable and program by digging through’s copy of the Microsoft website, extracting a self-inflating executable in a Windows virtual machine, then copying that file over to my Mac. Then I could copy my files in the right hierarchy and run a command to compile a directory with of the executable and BASIC programs to something that could be run in the browser.

If you want to mess around with the programs right now, you can skip to the bottom of the post.

The tree structure that I had looked roughly like:

├── src
│   ├── dosbox.html
│   ├── dosbox.html.mem
│   ├── dosbox.js
│   ├── myqb
│   │   ├── QBASIC
│   │   │   ├── BASIC
│   │   │   │   ├── ...
│   │   │   ├── ...
│   │   ├── QBASIC.HLP
│   │   ├──
│   │   ├── qbasic.exe
│   │   └── qbasic.html
│   ├──
│   ├──
│   ├── qbasic.html
│   └── ...
├── ...

The command to compile it was:

$ ./ qbasic myqb qbasic.exe

The second argument specifies where all of the files are (where C:\ is mounted). The last argument is which executable to run when DOSBox starts up. The first argument is the name of the .html and associated .data file that will be generated.

You need to copy the following files to be able to host it standalone:

  • dosbox.html.mem
  • dosbox.js
  • (or whatever your .data file is called)
  • qbasic.html (or whatever your .html file is called)

The files in, say, myqb, aren’t actually needed since they are compiled to the .data file when you run the packager program.

The programs

The QBasic programs are located here.

The DOSBox emulator will load when you go to that page and immediately run QBasic. To load a program, File, Open and navigate under the QBASIC directory. (Yes, the files back then needed to be in 8.3 format.) Under each folder is a set of programs and related assets.

There are a couple of potential issues with running the programs.

One is that some of the programs relied on me pressing Ctrl + Break and most keyboards today don’t have the Break key. Plus, I think there are some issues with how DOSBox handles the Ctrl+Break combo normally, which is likely only exacerbated when running inside of a browser.

The other is that I originally had them in different places on my drives (hard and floppy) so the paths to certain assets might not be hooked up entirely correctly. But at least it is up there in some form.

Parting thoughts

If you would have asked me if I would be running programs that used all of the resources of the computer at the time in the web browser of a future computer, I’m not sure that I would have believed you. But, if exponential increases in hardware efficiency continue, the things that are most taxing today might be trivial in the future. Everything you are currently running on your computer might be emulated in a chat client in the future. :)

I may write up some of the programs in an index up there, but it might be a while before I get to it. Until then, feel free to poke around!

  1. There is an open issue related to the ability to persist disk changes between page reloads. 

Categories: main

« Deciding From Multiple Open-Source Alternatives Ignore URLs and Acroynms While Spell-checking Vim »