wxBasic
A small LGPL BASIC interpreter that wraps the wxWidgets C++ toolkit almost method-for-method - written by David Cuny in 2001, abandoned by him in 2006 mid-rewrite, and quietly carried on by Ralf Peters ever since, with releases numbered after the wxWidgets version they link against
Created by David Cuny; maintained since the mid-2000s by Ralf Peters
wxBasic is a small, LGPL-licensed BASIC interpreter whose entire reason for existing is the library sitting behind it. It wraps wxWidgets - the cross-platform C++ GUI toolkit that renders with native controls on Windows and GTK on Linux - and exposes it to a QBasic-shaped language with almost no translation layer in between. Classes are instantiated with New, methods are called with a dot, constants keep their wxID_EXIT spelling, and the effect is that the wxWidgets C++ reference manual doubles as the wxBasic manual. A complete windowed program is two lines:
| |
It is also a language with two distinct lives. David Cuny wrote it over 2001 and 2002, put out six numbered releases in six months, decided the architecture was wrong, started again from scratch, and stopped in May 2006 with the rewrite unreleased and the website frozen on a list of three things still to do. That page is still online, still dated Friday, May 12, 2006, twenty years later. Meanwhile the code did not stop: Ralf Peters picked up the unreleased rewrite, and has been shipping it - quietly, from a different domain, in eight releases spread across sixteen years - ever since. The version most people mean when they say “wxBasic” is Cuny’s 0.52 from 2002. The version you can actually download dates from July 2024, and the project cannot quite agree with itself on what to call it: the download page says 3.2.2.51, the installer file is named SetupWxBasic-3.2.5.52.exe, and the release note says wxWidgets 3.2.5.
History and Origins
It was supposed to be a different language
The acknowledgements page of the 2001 manual is unusually candid about how the project came about:
I’m not sure if there’s a lot of demand for Yet Another Basic Interpreter, but here it is anyway. A number of people are to thank (or reprimand) for this project getting this far.
First, thanks for Everett (Rett) Williams for encouraging me to port my Py programming language to C. Somewhere along the line (much to his consternation) Py became wxBasic. So go the best laid plans of mice and men.
The same page credits Brian Kernighan and Rob Pike directly for the implementation: “I’m especially indebted to Brian Kernighan and Rob Pike for the books The Unix Programming Environment and The Practice of Programming. The core of wxBasic is built around the ideas they presented in these texts.” The rest of the list is a snapshot of what free tooling looked like to a hobbyist language implementer in 2001 - Bison for the grammar, the free Borland C++ compiler and MinGW, Bloodshed Dev-C++ for an IDE, UPX to squeeze the executables, and Basser Lout and GhostScript to typeset the manual.
2001: six releases in six months
The earliest surviving snapshot of the site, from 16 November 2001, shows a project moving fast. Linux support had landed on 3 October; UPX compression of the binaries on 8 October; version 0.33 “Pumpkin Patch” - with associative arrays, Option NoConsole, a Common statement for globals, short-circuiting And and Or, and Mines and FreeCell demos - on 30 October. SourceForge hosting arrived on 7 November. 0.41 “Green Aphid” followed on 30 November, 0.50 “Partially Hydrogenated” at the end of December - the site dates it the 27th, the SourceForge file the 28th - and a “bleeding edge” build on 13 December.
Releases were named as well as numbered, in a tradition the project shared with nothing else in particular: Pumpkin Patch, Green Aphid, Partially Hydrogenated, Waltzing Intertia (the typo is the author’s), Basidium-X. Version 0.51 arrived on 12 March 2002 and 0.51a a week later. 0.52 “Basidium-X” - OpenGL support, fixed string-returning wxWidgets calls, a fixed shroud.wx - was the last, and it is the one the world remembers. Its date is the first small archaeological problem the project presents: the 2002 site says 10 March 2002, the 2006 site says 22 March 2002, and the file on SourceForge is stamped 11 April 2002.
2002-2006: the rewrite that was never released
By his own account Cuny concluded in 2002 that the original interpreter needed replacing:
Back in 2002, I decided that it was time to rewrite wxBasic from the ground up. This codebase will replace the “official” wxBasic, which was last updated back in March 2002. The new version has an entirely different architecture, and provides quite a number of features that are not available in the old version. At this point, I consider it more bug-free than the “official” release.
The new codebase - referred to informally as wxBasic 2 - was distributed only as dated “bleeding edge” builds, never as a numbered release. Its console binary was called bvmc, and the vm in that name is the substance of the “entirely different architecture”: where the original walked a parse tree, the rewrite compiled to bytecode for a virtual machine, which is what accounts for the description of wxBasic as a bytecode language in most later summaries.
Three things were holding up an official release: OpenGL support, finishing the documentation, and bug fixes. The last bleeding-edge build is dated 12 May 2006, and so is the last update to the website. Nothing in the SourceForge file area has moved since 2002. A third-party GitHub mirror created in 2015 preserves what its author believed to be the final build, under the filename wxb2_12-may-2006_bleedingedge.
2006-2024: the second life
Ralf Peters began working on the abandoned rewrite in 2006 - the earliest surviving capture of the new site, wxbasic.net, carries the footer “(c) 2006-2008 Ralf Peters and David Cuny” - and the first public build under the new maintenance appeared in September 2008, linked against wxWidgets 2.8.8. Development has continued at roughly the pace of one substantial release every two to three years since, credited on the current site to “the Solution Research development team, leaded by Ralf Peters”.
The version numbers explain the project’s whole relationship with its dependency. 2.8.12.37, 2.8.12.41, 2.8.12.43, 3.0.2.45, 3.0.5.50, 3.1.5.50: the first three components are the wxWidgets release the interpreter links against and the fourth is wxBasic’s own build counter. The scheme is applied loosely enough that the current release is labelled 3.2.2.51 on the download page while its installer is named for 3.2.5.52 and its release note says wxWidgets 3.2.5. A release of wxBasic is, in effect, a release of wxWidgets with a BASIC in front of it, and the changelogs read accordingly - long lists of newly wrapped classes, punctuated by the occasional change to the language itself.
Design Philosophy
The original manual states the goals as a five-item list:
- Free (Lesser Gnu Public License)
- Cross-platform GUI support via wxWindows library. Runs in Windows and Linux
- Easy to learn, based on Basic
- Interpreted
- Small footprint (fits on a floppy)
Two of these deserve unpacking.
“Easy to learn, based on Basic” means specifically QBasic, not Visual Basic. The project’s front page has said “wxBasic looks a lot like QBasic” since 2001, and there is an Option QBasic statement in the language. What it borrows from Visual Basic is the ambition rather than the syntax: the idea that a beginner should be able to put a window on the screen without learning an object framework first. What it explicitly does not borrow is the deployment model. The pitch, repeated on the site for two decades, is that unlike Visual Basic a wxBasic program can be bound into a single executable that needs no DLLs, no runtime, no resource files and no installer.
“Small footprint” was a real design constraint, not a slogan. The 2001 download page listed the 0.33 Windows package at 519K and the Linux one at 1.4M - these are the sizes the site advertised for the downloads rather than measured binary sizes, and the site had already had to correct the Linux figure once, “from 224K to 1.4M” - and the manual is at pains to point out that the whole system fits on a floppy disk. The executables were UPX-compressed from October 2001, a tool the manual credits for “much of it’s small size”. This is also why the language ended up in Puppy Linux, a distribution built around the same constraint.
The deeper design decision is the one about the object interface. From the manual:
wxBasic attempts to mimic wxWindow’s C++ interface. This means that, allowing for the fact that wxBasic isn’t C++, most of the documentation on wxWindows can be applied to wxBasic in a rather trivial manner.
This is a genuine trade-off and the project made it deliberately in one direction. A more idiomatic BASIC binding would have hidden wxBoxSizer and wxEVT_COMMAND_BUTTON_CLICKED behind friendlier names and cost itself the ability to reuse the upstream documentation. wxBasic chose the documentation. The cost shows in the manual’s list of restrictions - you cannot chain method calls, for instance:
| |
Key Features
The original language
Cuny’s wxBasic is a variant-typed, case-insensitive BASIC with a small keyword set - 45 reserved words in the 2001 manual - and a handful of pointed deviations from tradition:
| Feature | wxBasic |
|---|---|
| Variables | Auto-created on assignment; all values are variants and coerce on use. Option Explicit requires declaration, and then module-level variables must be pulled into a routine with Shared |
| Arrays | Indexed with square brackets, Dim list[10,32], freeing () for calls. Dynamic arrays and Awk-style associative arrays with string or numeric keys |
| Parameters | Everything is passed by reference |
| Statement separator | : joins statements on a line; a statement can be split across lines after any operator |
| Blocks | Both While ... Wend and While ... End While, both For ... Next and For ... End For, plus For Each |
| Objects | New and Delete; an object created without New is stack-like and destroyed when its routine exits |
Events were wired up with a Connect() function taking the callback’s name as a string:
| |
Under Peters the same thing can be written with a Handles clause on the function itself, binding the event where it is declared rather than by a name in a string. The release notes do not say which version introduced it; it is in use in the maintainer’s own examples by 2021:
| |
Binding and shrouding
Two utilities shipped from the beginning, both written in wxBasic itself. bind.wx produces a stand-alone executable by appending the source to a copy of the interpreter binary and writing a tag at the end; on startup the interpreter checks for the tag and runs the attached program if it finds one. shroud.wx renames user-defined routines and variables to meaningless identifiers, leaving anything beginning with wx alone. Both were marked “still in alpha development” in 2001 and neither handled Include files. The binding trick survived every rewrite; the December 2018 release added an option to disable the interpreter’s access to embedded source, closing the obvious hole in it.
Implementation
The 2001 interpreter is a textbook one and the manual documents it as teaching material: lexer.c tokenises, a Yacc grammar in wxbasic.y - built with Bison, which the acknowledgements thank as “a free version of YACC” - produces a parser that builds a parse tree of opcode-tagged nodes, and an evaluator walks the tree, freeing each statement block after evaluating it. Types are wrapped C++ classes registered in the symbol table by wrap.cpp. The whole system is C with a thin C++ layer touching wxWidgets - the arrangement that keeps the interpreter small and portable while the toolkit does the platform work.
The modern system ships as three binaries with three different amounts of wxWidgets linked in:
wxbasic- the full GUI interpreter, linked against all of wxWidgetswxbc- a console interpreter linked against wxBase, wxNet and wxXml only, for background jobs that need sockets, XML and databases but no windowsbvmc- a plain console interpreter, the closest thing to QBasic in the set
It also carries a great deal that no 2002 user would recognise: a source-level debugger with breakpoints and stepping, a wxReportWriter class that is not part of wxWidgets, a database layer that has been rebuilt three times (wxDb, then wxDatabaseLayer, then wxDbConnection in 2024) over ODBC, SQLite, MySQL and FreeTDS, and bindings for wxAui docking, wxRibbonBar, wxRichTextCtrl, wxStyledTextCtrl, wxDataViewCtrl, wxWebView and wxMediaCtrl.
Evolution
The clearest way to see the project’s shape is as a list of what each maintainer changed.
Cuny, 2001-2006. Built the language, the manual, the binding and shrouding tools, and the OpenGL support in 0.52; then rewrote everything around a virtual machine and never shipped it.
Peters, 2006-2024. Never changed the language much - the 2024 syntax is recognisably the 2002 syntax - and instead kept the wrapper surface abreast of a toolkit that itself went through three major versions. The genuinely language-level changes are few and well spaced: Handles and iif() in 2008; the debugger in 2011; Unicode throughout and a widened integer type in 2014; wxbc and console-style GUI statements in 2016; embedded-source protection in 2018; wxImageFromEmbedded and Apple Silicon support in 2021; SVG bitmaps and a WebView2 backend in 2024.
Platform support, as documented on the download page, is Windows (32- and 64-bit, from a single installer since 2024), macOS 64-bit including Apple Silicon, and 64-bit Ubuntu as a .deb. The builds are not all at the same version - as of September 2026 the download page offers 3.2.2.51 for Windows, 3.1.5.50 for macOS and 3.0.2.45 for Linux - and the maintainer has been open since 2011 that the non-Windows builds get less testing. A Windows Arm64 build was described as work in progress in the 2024 release note.
Current Relevance
wxBasic is not dead, but it is very quiet. The signals point in both directions and it is worth being precise about them.
Against activity: the SourceForge project has received no file since 2002 and its website has been frozen since 2006. There is no upstream source repository - the only GitHub presence is a 2015 mirror of a 2006 build, made by a third party. There is no package in any mainstream distribution’s repositories, no Docker image, no Rosetta Code category, and no visible forum. The original author has been gone for two decades.
For activity: there was a full release in July 2024, on a current wxWidgets, with a rebuilt website and a new database layer, and the copyright line on that site reads 2026. Eight documented releases since 2008 is not a fast pace, but it is a pace, and the twenty-three years between the first release and the most recent one are longer than most of the languages wxBasic was competing with in 2002 managed to stay alive at all.
The honest characterisation is a single-maintainer project with a working product, no community, and a release cadence measured in years - dormant by the standards of a language ecosystem, maintained by the standards of a tool.
Why It Matters
wxBasic is a good example of a category that was crowded around the turn of the millennium and has almost entirely disappeared: the free BASIC that existed to make a GUI toolkit reachable. Visual Basic had made it obvious that beginners would build desktop applications if the distance from idea to window was short enough, and had equally obviously tied that to one vendor and one platform. wxBasic, along with the other members of its family, was an attempt to get the first half without the second, and its particular answer - wrap the toolkit so thinly that its documentation still applies, then bind the whole thing into one file with no dependencies - was a good answer to the question as posed.
It also produced two artefacts worth more than the language. Its interpreter core became SdlBasic, which went off and had a career of its own in a different domain. And it became part of Puppy Linux, where a simplified fork of it was the scripting language a whole small-distribution community used to build desktop utilities. Very few hobby languages are used by anyone but their author; wxBasic ended up shipping, under a different name, on machines whose owners had never heard of it.
Finally, it is an unusually complete specimen for anyone interested in how projects actually die and don’t. The original site is still there, frozen mid-sentence on a to-do list from 2006, and the language it describes is still being released - by someone else, from a different domain, under version numbers borrowed from a C++ library. Both pages are online today. They describe the same software, the frozen one from 2006 and the live one from 2024, and neither mentions the other.
Timeline
Notable Uses & Legacy
Puppy Linux
The single widest deployment of wxBasic. A simplified variant, wxBasicscript - later renamed PuppyBasic - with Linux-specific functions and pre-built dialog helpers added by Mark Ulrich, was "included standard in Puppy 1.0.5 and greater" according to the distribution's own wiki, making a wxBasic interpreter part of a Linux distribution that fit in a few dozen megabytes and ran from RAM
SdlBasic
Roberto Viola began SdlBasic in December 2002 after the idea of putting the SDL libraries behind wxBasic's interpreter. Its core is based on wxBasic with SDL substituted for wxWidgets; it went on to have its own release history and IDE, and is the clearest case of wxBasic's implementation outliving its own project in someone else's hands
wxEditor
A programmer's editor written in wxBasic itself, credited in the project's own release notes to Dirk Noack (spelled "Dirk Noak" in the May 2011 note) and shipped inside the distribution. Version 4.0.2 was folded into the May 2011 release. It is both the project's IDE and its largest demonstration program - a wxStyledTextCtrl-based editor written in the language it edits
Scheduled and background jobs
The maintainer's stated primary use case for the wxbc console build: "complex time controlled jobs" combining wxBase, socket and HTTP processing, string handling and ODBC, SQLite, MySQL or SQL Server access. The presence of a report writer (wxReportWriter, not part of wxWidgets) and a hand-written SQL parser in the interpreter points at internal business tooling rather than desktop applications
Prototyping wxWidgets applications
The use case the project pitches to C++ programmers: because the wxBasic object interface mirrors the wxWidgets C++ API closely enough that the C++ documentation applies almost unchanged, a wxWidgets developer can try a layout or a control interactively and only then decide whether to rewrite it in C++ - avoiding, in the maintainer's words, "a time consuming loop of edit, compile, link, test and start all over again"