XBasic

XBasic is a BASIC that skipped the 1980s. While the rest of the family was living in 64KB of DOS memory, arguing about line numbers and taking whatever Microsoft shipped next, XBasic was written from scratch in 1988 for a Motorola 88000 RISC workstation running UNIX - 32-bit, virtual-memory, case-sensitive, and structured entirely around functions. By the time Windows programmers got their hands on it, it had been ported to Windows NT (in 1992, against pre-release builds, so that it was ready the day NT shipped), to SCO and ESIX UNIX, and finally to Linux in 1995.

Then it stopped. Its author’s own FAQ admits it: “XBasic has not been worked on in a major way since 1995.” What happened afterwards is the interesting part - a freeware release in 1999, an open-source release in 2000, a maintainer, a SourceForge project, a last official version in 2002, a development page that promised the next release “shortly” for more than a decade, and then, two decades later, a handful of people quietly building it again.

History and origins

Max Reason - the name under which the author published everything, alongside work in optics, astronomy, telescope instrumentation and image processing - built XBasic as a tool, not a product. The first implementation, in 1988, targeted the Motorola 88000 (the 88100 CPU and 88110 successor both appear in the XBasic documentation index) under UNIX. That choice explains almost everything unusual about the language. There was no 640KB barrier to design around, no segmented memory, no 16-bit integer as the natural word size. XBasic could assume a flat 32-bit address space and a virtual-memory process from its first line of code, and it did: the overview page still boasts that “every program is a 32-bit virtual memory process, so programs and data can greatly exceed the limits of memory.”

The 1992 Windows NT port is the pivot. NT was the first Microsoft operating system that looked like the machine XBasic was written for, and Reason tested against alpha and beta developer pre-releases so the compiler was available when NT was released. The 88000 and SCO implementations were left behind, not kept up to date. Linux followed in 1995, developed against a Caldera distribution and drawing every pixel through Xlib.

And in 1995, effectively, development ended. XBasic existed, worked, and sat still.

It re-emerged on 5 May 1999 or thereabouts, as freeware, on a personal web site. The reception is preserved in the author’s newsbits log and is oddly touching. On 3 June 1999 a user named Dale Maggee installed the four-year-old Linux build on Red Hat 5.1 and reported back - “SUCCESS!!! It worked!!!” - because Reason had by then sold his Linux machines and could not test it himself. Two days later an anonymous contributor donated a complete HTML conversion of the Word documentation, which Reason adopted on the spot as “living documentation”. On 10 June he announced a contest to redesign the IDE’s main window, after a new user built a better one with XBasic’s own GuiDesigner and sent it to him.

On 21 January 2000, at version 6.0001, the whole thing went open source - GPL for the language and environment, LGPL for the runtime libraries so that applications built with XBasic could stay closed. A SourceForge project had been registered two days earlier, and Eddie Penninkhof took over maintenance.

Design philosophy

The overview page states the goal plainly: XBasic “was developed from a clean slate to be simple, consistent, readable, intuitive, and powerful - and 32-bit from the ground up. As a result, XBasic is free of complexities and implementation dependencies other computer languages could not avoid, given the era in which they developed.”

In practice “clean slate” meant breaking with BASIC in three specific places.

Case sensitivity. XBasic is fully case-sensitive, like C. The FAQ gives the reason directly: without it, “its compatibility with operating-systems, APIs, and function-libraries would have been severely limited.” A language that intends to call CreateWindowExA cannot be casually case-folding identifiers.

Real tokenisation. Classic BASIC parsers consumed keywords greedily wherever they found them. The FAQ’s example is FORK=ATOM, which old-style BASIC reads as FOR K = A TO M - six language elements. XBasic reads it as three: a variable named FORK, an =, and a variable named ATOM. Whitespace separates tokens, and keywords are not magic substrings.

Pass by value. Most BASICs pass arguments by reference by default; XBasic passes by value, and lets the caller opt into by-reference per call site with @, or by-address with & for C compatibility. The implementation is a neat trick, described in the FAQ: everything really is passed by value, and for arguments marked @ the compiler emits code after the call that reads the final value back and assigns it to the caller’s variable. The callee cannot tell the difference, which is exactly why the same function can be called with any mix of the two.

The program development environment

XBasic was always sold as an environment rather than a compiler, and the environment is genuinely strange by modern standards.

Programs are stored on disk as plain text, always. But when the PDE loads a program it converts the text into binary tokens and keeps it in that form for editing, execution and debugging - converting back to text, one function at a time, for display. You see a single function at a time and switch between them; a “text mode” toggle turns the whole program back into an ordinary editable buffer, at the cost of being unable to run or debug it. Because the tokens preserve spaces and tabs, round-tripping between the two forms does not disturb your formatting.

The interface is driven by dot-commands typed into a text area: .fn p for File/New/Program, .fl ademo.x for File/Load, .rs to run, each built from the initials of the menu path it replaces. Every widget - XBasic calls them all “grids”, whether labels, buttons, menus, scroll-bars or text areas - answers a right-click with a context-specific InstantHelp window.

A minimal program looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

'
' Programs contain:
' 1. A PROLOG with type/function/constant declarations.
' 2. This Entry() function where execution begins.
' 3. Zero or more additional functions.
'
FUNCTION Entry ()

  PRINT "hello world"

END FUNCTION

There are no line numbers and no top-level statements. Execution begins at Entry(), and everything else is a function.

Compilation model

XBasic is a compiler, not an interpreter, but it has two modes. Inside the PDE, running a program translates the tokens directly into executable machine instructions in RAM and jumps to them - no intermediate files, no external toolchain, which the documentation credits for the speed of the edit/run/debug cycle. No published benchmark puts a number on it. When you are finished, the compiler emits an assembly language file together with a makefile describing how to assemble and link it into an EXE or a DLL. On Windows this meant a subset of the Cygnus GNU utilities, which the project distributed separately.

Functions are C-compatible in both directions. XBasic functions follow the STDLIB (stdcall) protocol by default, which is what the Win32 API uses, and CFUNCTION declares the C calling convention instead. XBasic programs can call API functions directly - the documentation just asks you not to, unless the supplied libraries cannot do the job, and specifically warns against working around the XBasic message queue.

Language features

Built-in complex arithmetic and a matrix library in a BASIC aimed at beginners is an unusual combination, and reflects who wrote it: the same person whose other pages are about spectroscopy, telescope control and image processing.

Evolution, and the long pause

The open-source years were brisk and then abruptly not. Six releases landed in 2000 alone, from 6.1.0 in May to 6.2.0 in late November. Then 6.2.1 in July 2001, 6.2.2 in January 2002, and 6.2.3 on 27 October 2002 - the last release from the official maintainer.

What makes the silence unusually legible is the SourceForge page, which was never taken down and never updated. Under the heading “Unstable (or ‘beta’)” it read: “Version 6.1.4 was the latest unstable version but development on the 6.1 tree has now moved into the 6.2 tree. Version 6.3.0 will be available here shortly.” Wayback captures show that sentence unchanged in 2003, in 2009, and in 2013. The beta download table underneath continued to offer files dated October 2000.

Meanwhile the fork did the living. XBLite, started by David Szafranski in 2001 and first released in October 2002, kept XBasic’s syntax but bet on Windows alone, replacing the portable graphics layer with direct Win32 calls and acquiring an editor, a GUI designer, a peephole optimiser and an API wrapper library over the following years.

XBasic proper came back, quietly, much later. A build numbered 6.3.26 was produced by a contributor known as CW2008 and stamped 10 June 2018, circulating through the mailing list rather than any web site - which is why most reference works still list it as the latest version. In April 2021 an xbwlteam organisation appeared on GitHub with Windows and Linux repositories; in September 2021 the SourceForge file area opened for the first time in almost nineteen years. Community builds 6.3.26-A, -B1 and -C followed through 2022, along with XBSourceLib and refreshed documentation. Source tarballs labelled 6.4.3 and 6.4.5 appeared in 2023 and 2024, their file names marked linux64 - an attempt at the one platform the resolutely 32-bit original was never built for.

Current relevance

XBasic today is a preservation project. The language has not gained a feature since the 1990s; the recent work is about keeping a 1990s codebase compiling and running on current systems, which for a compiler that emits its own assembly and links through GNU tools is real work. The community is small and concentrated in one mailing list and one GitHub organisation.

Its most visible footprint is on Rosetta Code, where 129 tasks carried an XBasic solution when the category was counted in September 2026 - almost certainly more XBasic than most people will ever encounter anywhere else. Its most successful descendant, XBLite, is still being released.

Why it matters

XBasic is a useful counterexample to a comfortable story about BASIC. The usual account is that BASIC was a beginners’ language that grew up badly - line numbers, then GOTO-riddled microcomputer dialects, then Visual Basic’s event-driven forms, with cleanliness arriving only when Microsoft rebuilt it on .NET. XBasic shows that a structured, case-sensitive, statically typed, 32-bit BASIC with C-compatible calling conventions, complex arithmetic and a portable GUI toolkit was achievable in 1988, by one person, on a RISC workstation - and that the constraint had never really been the language family.

It is also an unusually complete demonstration of self-hosting as a design principle. The compiler, the debugger, the editor and the GUI builder are all XBasic programs, calling no C library by the author’s account, layered so that exactly one component knows what operating system it is on. That is why a graphics-heavy program moved between Windows and Linux unchanged in 1999, at a time when portable GUI code was an ambitious claim.

And it is a case study in what the open-source moment actually did for languages like this. Releasing the source in January 2000 did not revive XBasic; the author had already moved on, and the official project produced nine more numbered releases before falling silent for nearly nineteen years. But it did make the language survivable. XBLite could be forked because the source was there. The 2021 revival could happen because the source was there. Plenty of commercial BASIC compilers from the same era are simply gone. XBasic, frozen and obscure, is still buildable.