DIM A%(12000000000)
…and have it actually work. Then I kept adding things. The result is Thoreau BASIC, a free x64 BASIC interpreter inspired by GW-BASIC, running both as a normal Windows program and directly on bare-metal UEFI without an operating system.Version 3.2 has become considerably more ambitious than the little interpreter I originally intended to write. The language still deliberately looks and feels like old Microsoft BASIC. Line numbers, GOTO, GOSUB, PRINT, PSET, LINE, CIRCLE, DRAW, etc. are all there. But underneath that rather innocent-looking surface is now quite a lot of machinery.
Some of the current features:
native x64 JIT compilation, with automatic fallback to the interpreter
PARFOR for multithreaded numeric loops
SSE2 / AVX2 acceleration where available
64-bit addressing and very large arrays
native complex, quaternion and other hypercomplex numbers
arbitrary-resolution 24-bit graphics
sprites, bitmap operations, polygon filling and mouse input
TCP/IP networking on Windows and UEFI
an integrated profiler, debugger, tracing and program-analysis tools
CREATEEXE to turn a BASIC program into a standalone Windows executable
CREATEEFI to turn the same program into a directly bootable UEFI application
The sound system has also grown rather out of proportion. Thoreau BASIC can now handle up to 32 live instrument channels plus 64 sound effect channels and 256 voices, with real-time pan and brightness control. NOTE and SOUNDKEY can be used more like playable synthesis primitives rather than just old-school BASIC beeps.3.2 also expands the less glamorous but surprisingly useful parts of the environment. There is better file browsing and selection with GETFILES and SELECTBOX, longer case-preserving paths, recovery/file-flush facilities, and considerably more detailed SYSTEMINFO$ diagnostics. The latter is useful for seeing things such as available CPU capabilities and the execution environment while debugging performance differences between machines.
One thing I've spent a lot of time on recently is making the BASIC programs themselves fast enough that they stop feeling like demonstrations of an interpreter. For example, the current Mandelbrot demo is a real-time interactive fractal explorer. Mouse movement pans the fractal, left-click zooms in and right-click zooms out, while the BASIC program continuously redraws and displays the frame rate.
There are also 3D and procedural demos, sprite programs, networking examples, hypercomplex fractals and games. An important design constraint throughout the project has been that Windows and UEFI should execute essentially the same BASIC language. A program shouldn't suddenly become a different species just because there is no operating system underneath it.
And yes, I am fully aware of the absurdity of combining GOTO 100 with AVX2, multithreading, TCP/IP and quaternion arithmetic. That is increasingly the point. I'm interested in the question: What would BASIC look like if it had never gone out of fashion? Thoreau BASIC 3.2 is my current answer.
I'd be especially interested in feedback from people who remember GW-BASIC/QBasic, compiler/interpreter people, and anyone sufficiently unreasonable to enjoy the idea of booting a modern x64 PC directly into a BASIC interpreter/JIT compiler.
Show HN: I wrote a BASIC interpreter that boots on UEFI machines - https://news.ycombinator.com/item?id=49410814 - Aug 2026 (44 comments)
I still think VB.NET is vastly more readable than C/C#/Java etc.
Unfortunately it was a one-to-one match to C#.
It would have been much netter if it was based on Visual Basic 6
VB.NET can do everything what you can do with C#. Saying that C# is better than VB.NET is like saying that French is better than Spanish.
For example, the new async/await runtime model is also for VB.
VB 6 way to do COM still wins out, though.
VB.NET and C# was treated as equals for a long time. I believe MS initially expected VB.NET to be the mainstream .net language, while C# was a compromise to attract Java and Delphi users.
But the transition from VB to VB.NET was not handled well. VB was very well liked by its users (even if non-users looked down on it) but VB.NET was worst of both worlds. Too different from VB to be smooth upgrade, and still nok considered as professional a language as C#
The real Visual Basic not by Microsoft is TwinBASIC(closed source).
I feel like that kind of event-driven programming model was very intuitive, even for younger audiences.
Later, the VAX had BASIC with functions and subroutines and dropped the line numbers and this version of BASIC was significantly better. It was procedural, but you could organize your code into modules, keeping it readable and maintainable.
Eventually the non line number BASIC spread to the PC. Microsoft Professional Development System, then Visual BASIC.
Check PureBasic. https://www.purebasic.com/
Compiles to native, interfaces to C libraries, available on most platforms...
Fast during development, fast results, flexible, well conceived, a pleasure to work with...
That is the real 'what if it had not gone out of fashion' path. VB/DOS definitely went out of fashion. GUI BASICs became fashionable, instead. Everyone who does a 'visual' BASIC nowadays does a GUI one.
The headlined BASIC is nothing like a VB/DOS for EFI, though.
That wasn't the case with GW-BASIC, due to how MS-DOS came to be.
However the idea of an EFI BASIC does sound rather nice, assuming the whole plethora of graphics programming as well.
Other take the easy way out with RISC OS for the Raspberry PI, which has BASIC as main programming language alongside Assembly.
I'm talking more about the distinction between VB/DOS and VB/Windows. They both did the whole WIMP thing, with a visual editor to construct the forms for one's programs, but VB/DOS used a TUI rendering that drew everything with VGA character graphics and used the firmware low-level keyboard access for input; whereas of course VB/Windows used the Windows GUI.
A VB/DOS-alike that ran on EFI and did the whole form-based programming thing, would use the EFI text input and output protocols, which know Unicode, waiting for events, and standardized scan codes and modifiers.
There is no major call for it, as you say, when bootstrapping an entire operating system is so easy. But it would be interesting to see someone tackle it from the point of view of what VB/DOS would look like today if it ran directly on the firmware, spoke Unicode, and ran in protected mode
A Phoenix like BIOS UI.
- SOUND PRELOAD
- SOUND INFO
- SOUNDGROUP
- SOUNDNAME$
- SOUNDAVAILABLE
- LOADWAV
- PLAYWAV
- STOPWAV
- WAITWAV
- PAUSEWAV
- RESUMEWAV
- WAVCTL
- DELWAV
- WAVACTIVE
- WAVPLAYING
- WAVSTATE
- WAVPOS
- WAVLENGTH
- WAVLOADED
- WAVSLOT
- WAVCHANNEL
- LOADMID
- PLAYMID
- STOPMID, WAITMID, DELMID, etc.
What a terribly designed language.If you were a new computer user in 1980, your Appie II+ or PET 8032 booted straight into BASIC, and it was a good-enough tool that could do productive development for the entire life of the machine there.
But if you were a new computer user in 1990, you didn't have that. They gave you GW-BASIC, and if you're lucky a separate manual rather than a vague chapter in the main DOS manual. This might be enough to give you some initial experience with programming, but you have a bunch of hard brick walls.
Your machine might have 640k-4Mb of memory, but GW-BASIC can only meaningfully work with 64k of it. You can't access the mouse or any post-EGA graphics modes without a LOT of assembly shimming. If you had a sound card, it was outside the built-in tooling.
Remember, this is a few years before the Internet being widely available, and stuff like the GNU project being widely accessible. This is probably the best development tool you have available
If you wanted to go further in programming, it meant buying a boxed compiler that probably cost well in excess of USD100, and was for a completely different language than the one you had cut your teeth on.
But if you wanted "The GW-BASIC I already understand, but more", you want this.