XBLite

XBLite is what happens when someone takes a good, orphaned compiler and decides that it should be one thing rather than two. XBasic - Max Reason’s clean-slate, 32-bit, case-sensitive BASIC from 1988 - had been portable between Windows and Linux since 1995, and paid for that portability with an entire abstraction layer: a GraphicsDesigner that was the only component allowed to touch the platform, and a GuiDesigner that drew everything by asking GraphicsDesigner to do it. Reason had stopped serious work on it in 1995, released it as freeware in 1999 and open-sourced it under the GPL in January 2000. In 2001, David Szafranski forked it, threw the portability layer away, and pointed the language straight at the Win32 API.

That is the entire design decision, and twenty-five years of the language follow from it. XBLite does not run on Linux and never has. In exchange, an XBLite program can call any Windows API function, embed dialog and icon resources, build as a console application or a GUI application or a DLL, link statically so that it has no runtime dependencies at all, and drop into inline assembly wherever the programmer feels like it.

History and origins

The first public release, version 1.0.0, came in October 2002, and the project’s own copyright lines all start there - XBLite (c) David Szafranski 2002-2025 in the README, XBLite.org (c) 2002-2025 in the site footer. But the fork is a year older than that: the include files xmx.dec and xlib.dec and both licence texts still shipping in the 2025 distribution are stamped 12 and 24 December 2001.

The early 1.x releases read like someone carefully disentangling a codebase. CONSOLE and MAKEFILE keywords appear so that a program can declare how it wants to be built. The runtime DLL is renamed from xb.dll to xbl.dll specifically so that XBLite and XBasic can be installed on the same machine. Console I/O is moved out of the standard library Xst into a separate Xio. Start-up code that XBasic linked in from an object file is emitted by the compiler directly. By 1.4.0 there is an extended-precision LONGDOUBLE type; by 1.4.3 there is an EXPLICIT statement to catch misspelled variable names, added, the changelog notes, because “I have been told that an EXPLICIT statement is good for checking for mispelled variable names.”

In 2005, XSED arrives - a Scintilla-based editor, written in XBLite, which from that point on is inseparable from the language. In 2006 the project briefly acquires a team. Greg Heller rebuilds the compiler’s back end to emit code for Jeremy Gordon’s GoAsm assembler instead of XBasic’s own spasm, which becomes version 2.0.0; he follows it with static libraries, the m4 macro preprocessor and a long series of instruction-level optimisations. John Evans writes viXen, a GUI designer. Callum Lowcay writes WinX, a library that wraps the Win32 widgets. Ken Minogue rewrites exception handling. Guy Lonne begins a decade of contributions.

The peak of XBLite’s visibility is 2008: three articles by Guy Lonne in the PCOPY! webzine, a reported review in GMTech the previous year, and a Wikipedia article created in August recording compiler 2.4.0 and editor XSEd 1.30 as current. That compiler version stayed current for the best part of a decade.

Design philosophy

XBLite inherits its shape entirely from XBasic, and the shape is unusual for a BASIC. There are no line numbers, no GOSUB culture and no implicit anything. A program is a prolog of declarations followed by functions, the first-declared of which is the entry point:

1
2
3
4
5
6
7
8
9

CONSOLE
IMPORT "xst"
DECLARE FUNCTION Entry()

FUNCTION Entry ()
  PRINT "hello world"
  a$ = INLINE$ ("press enter to quit")
END FUNCTION
END PROGRAM

Four things in eight lines are worth noticing. CONSOLE is a build directive in the language itself, not a compiler flag. IMPORT "xst" names a DLL, and the import mechanism is the same whether the target is an XBLite library, a Windows system DLL or a C library. Every program needs at least one function, and functions must be declared before use. And the language is case-sensitive - Entry and entry are different names - which puts XBLite in a very small club among BASICs.

The type system is the other inheritance, and it is why XBLite has always been described as a BASIC with C’s reach. Alongside SINGLE and DOUBLE there are signed and unsigned 8-, 16- and 32-bit integers, a 64-bit GIANT (declared as GIANT tStart, tEnd, tFreq), an extended-precision LONGDOUBLE, composite TYPE and UNION declarations, and PACKED types for reading binary file formats without padding surprises. Variables can be AUTO, STATIC, SHARED or EXTERNAL, memory is managed automatically, and the project’s own site describes the result as combining “the speed of C with the ease of a modern BASIC syntax” - a marketing claim, offered without any benchmark or comparison.

The toolchain

XBLite is not really a compiler; it is a compiler plus everything around it, all of it written in XBLite.

The compilation model is deliberately old-fashioned and deliberately transparent. xblite.exe emits a GoAsm assembly file; GoAsm assembles it; GoLink or Microsoft’s link or Pelles C’s polink produces the executable. Since 2.42 the -go switch makes the whole chain Go-tools-only, which means an XBLite installation needs nothing from Microsoft and can link against DLLs without import libraries. The assembly file is left on disk, and XSED will show it to you - which in a language with inline ASM blocks and #defines emitted for every local variable is less a curiosity than an invitation.

Evolution

The project’s changelog is a strange document: complete, detailed, and almost entirely undated. What can be dated comes from announcements and from the compiler’s own internal revision log, and it describes a rhythm of long quiet stretches broken by bursts.

After 2.4.0 settled in around 2008, the compiler barely moved for eight years. Guy Lonne kept a parallel revision line alive on top of 2.41 from 2016 into 2018, adding CODE blocks for assembly injection, a GRAB keyword for code reuse, STRIP for size reduction, and an attempt at Windows Unicode support - work that circulated as source archives on the mailing list rather than as official releases. In the same period the project lost its best tutorial resource, when the hosting for Guy Lonne’s XBLite Book of Knowledge was discontinued in October 2016 and the community fell to mirroring it with HTTrack and saving pages as PDFs.

Szafranski returned in November 2020 with 2.42 and the Go-only toolchain, hosting it on a Google Sites page after xblite.com lapsed. Version 2.43 followed in February 2025 from the current site at xblite.org, and was mostly an XSED release - plus the integration of the GoBug debugger, which gave the language a source-level debugging story again.

Then, in 2026, the largest change since the GoAsm conversion. Szafranski’s progress report of 18 July 2026 describes a 64-bit port begun the previous year: every runtime assembly routine converted to the 64-bit fastcall convention, the standard library rewritten as Xst64, Xsx64 and Xio64, a first working 64-bit runtime around 18 March, the first program built by the 64-bit code generator on 24 March, and - the moment that matters for a self-hosting compiler - xblite.x compiling itself into xblite64.exe around 23 June. By mid-July all roughly 140 console demos built and ran as 64-bit programs, with GUI programs still to come. The beta is a 32-bit xblite.exe that can emit either 32- or 64-bit console code.

Current relevance

XBLite is a small language with a small community, and both facts are visible. The new SMF forum opened in June 2026 and had only a handful of topics by September. The Google Group carries a few threads a month, a New Year greeting each January, and a Christmas coding challenge. Wikipedia’s infobox still links to a SourceForge project that no longer exists. The documentation in the distribution was generated in 2010.

It is also, measurably, alive. Two releases in the last six years, an editor updated two months before this page was written, a GUI designer updated in July 2026, and a 64-bit compiler that has cleared the hardest milestone a self-hosting compiler has. Very few languages of XBLite’s obscurity can say that the same person who started the project in 2001 was still shipping code in 2026.

Anyone evaluating it should be clear about what it is not. It is Windows-only by design, not by neglect. It has no package manager, no test framework, no language server and no presence in any modern tooling ecosystem. Its third-party library story is a downloads page of zip files - SQLite, libcurl, zlib, expat, FreeImage, SDL, GLFW - each needing its DLL, LIB and DEC file copied into the right folder by hand.

Why it matters

XBLite is a useful counter-example to the way language death is usually described. Its parent, XBasic, is the more historically interesting language - written in 1988 for a Motorola 88000 workstation, 32-bit and virtual-memory-native years before the BASIC mainstream escaped DOS. But XBasic’s last official release was in October 2002, the same month XBLite’s first release appeared, and everything since has been intermittent community rescue work. The fork outlived the original by more than two decades of continuous maintenance.

It also stands as a small argument for a particular kind of project: one person, one platform, one narrow idea, held to for twenty-five years. The compiler is still the XBasic compiler in the sense that it still carries Max Reason’s copyright header, and it is not in any other sense - rewritten to a different assembler, restructured into a single executable, extended with types and keywords its original author never wrote, and now generating code for an instruction set that did not exist when XBasic was written. That is what a live fork looks like. Most forks are not.