BCX BASIC to C Translator

BCX is not a compiler. It is a translator: you feed bc.exe a file of BASIC source and it writes out a file of C — readable, formatted, human-editable C — which you then hand to whatever C or C++ compiler you already have. The result is a native Windows executable with no interpreter and no runtime DLL to distribute. Kevin Diggins started it in June 1999, and the striking fact about it in 2026 is that it is still shipping releases roughly every month, twenty-seven years later, from the same author.

The proposition is narrow and well aimed. Around the turn of the millennium there was a large population of experienced BASIC programmers — QuickBASIC, PowerBASIC, VB — whose language was steadily losing ground on performance and on access to the Windows API, and who did not particularly want to become C programmers to fix that. BCX let them keep writing BASIC while the C compiler did the optimisation, and it let them call Win32 functions and include C headers directly rather than waiting for someone to wrap them.

History and Origins

Development began in June 1999. The first implementation was, by the project’s own account, coded in PowerBASIC for DOS — a detail worth pausing on, because it means the tool that produced native 32-bit Windows programs was itself born as a DOS program. That did not last. BCX was progressively rewritten in its own language until, as the acknowledgements page puts it, the translator is written entirely in itself, making it a self-translating translator.

For most of its first two decades the project lived where a great deal of turn-of-the-century hobbyist software lived: a Yahoo Group for discussion, a SourceForge project for the source, and a scattering of personal sites for the distribution. The SourceForge project shows version 6.0 dated 6 June 2009, listed under GPLv2, described plainly as Windows only. Several volunteers carried the load over those years — the acknowledgements name Mike Henning and Wayne Halsdorf as source code maintainers, Ljubisa Knezevic for the built-in COM statements, and Robert Wishlaw for the help files.

Then it went quiet. There were several years with no meaningful development, and the project was heading toward the fate of most single-author tools of its generation.

What rescued it was, of all things, an infrastructure failure. When Yahoo Groups announced the changes that would gut its hosted communities, the BCX group needed somewhere to go. Jeff Shollenberger stood up BcxBasicCoders.com in October 2019 — twenty years after BCX started — with a forum and the full documentation. Diggins resumed development alongside it, with Wishlaw back on the documentation, and the release cadence that followed has been remarkably steady: the official revision history runs through version 7.8.9 in June 2022, 8.2.6 in March 2025, and 8.3.7 in mid-2026, with entries appearing most months.

A note on the record, because it is genuinely confusing: the SourceForge project still lists version 6.0 from 2009 and reports itself inactive, with a last update of 21 November 2019. That page is a fossil. Current BCX lives at BcxBasicCoders.com and is very much alive. Anyone judging the project’s health from the SourceForge listing alone would conclude it died seventeen years ago.

Design Philosophy

Translate, do not compile. BCX’s central decision is to stop at C source. It never generates machine code, allocates registers, or optimises anything. That sounds like a limitation and is mostly a strategy: it means BCX inherits, for free and forever, every optimisation improvement in the C compilers of the world. The generated output is documented as compiling with MS Visual C/C++, LLVM/Clang, MinGW32/64, Pelles C, LccWin32, Embarcadero C++, and the Intel C++ compiler. No small project could have produced a code generator competitive with any one of those, let alone all of them.

The generated C is meant to be read. BCX emits formatted, indented C rather than the dense machine-oriented output typical of source-to-source tools. This matters more than it sounds. It makes the translator debuggable by its users, it makes the output a teaching artifact — the official documentation includes a C++ tutorial written specifically for BCX users, teaching C by way of what BCX produces — and it means that when the abstraction leaks, you can see exactly where.

No barrier between BASIC and C. BCX does not try to wall you off from the host language. You can mix C code into BASIC source, use C libraries and header files without first translating them into BASIC declarations, and address Windows structures, variables, and the Win32 API directly. This is the feature that distinguishes it from a portable BASIC: the target is not an abstract machine, it is the Windows C environment, and the language exposes that deliberately.

No runtime to ship. The documentation’s recurring boast is that the resulting programs are among the smallest and fastest native Windows executables around and require no additional distributed runtime modules. That was a pointed claim in the Visual Basic era, when shipping a small utility meant shipping runtime files alongside it. Treat the “smallest and fastest” phrasing as vendor copy rather than a measured result — no published benchmark against a named baseline accompanies it. The verifiable part is the structural one: the output is ordinary compiled C, so it carries the size and startup profile of ordinary compiled C rather than that of an interpreted or VM-hosted language.

Key Features

A command-line translator with a compact option set. bc.exe is driven by single-letter switches. -c generates C++-compatible rather than plain C output. -u turns on Unicode support by emitting the _UNICODE and UNICODE macros. -h produces a header file; -l emits the runtime library source and header separately; -n disables runtime code generation entirely; -x and -z suppress the Win32 headers and the default headers and libraries respectively, for people who want to control the include set themselves. -d: defines constants from the command line, -w enables translation warnings, -e writes them to a file, and -s reports progress by line number.

Both C and C++ as targets. The -c switch is the hinge. Plain C output maximises compiler compatibility; C++ output opens the door to C++ libraries and to the object-flavoured facilities layered on top.

COM support built into the language. Statements for COM object manipulation — contributed by Ljubisa Knezevic — let BCX scripts drive automation-style objects in the way a Windows scripting language would, without dropping to raw IDispatch handling.

32-bit and 64-bit output. The translator produces source for both, and the distributed bc.exe is itself built as a 64-bit Windows binary with LLVM/Clang. This is what kept BCX viable past the 32-bit era, which finished off a good many of its contemporaries.

Console programs, GUI applications, and DLLs. All three are documented targets. The DLL case is the interesting one: it means BCX code can be a component inside a system written in something else entirely.

A distribution rather than a bare tool. Beyond bc.exe, the package has shipped code generators, GUI wizards, sample programs, and extensive help files, with DevSuite Pro as a larger bundle. For a self-taught BASIC programmer in 2003 this was the difference between a translator and an environment.

Evolution

BCX’s version history splits cleanly at 2019.

Before that break, the arc is the familiar one for a late-1990s BASIC tool: a DOS-hosted PowerBASIC prototype, a rewrite into its own language, a Yahoo Group of users filing bugs and contributing statements, volunteer maintainers picking up the source, and a SourceForge release line that stops at 6.0 in 2009 and then trails off. The technical trajectory in that period is toward Windows depth — Win32 structures, the API surface, COM, GUI generation — rather than toward portability or toward the language becoming more abstract.

After 2019 the project behaves differently. Releases are frequent and small, tracked in a public revision history, and the version numbers climb steadily through the 7.x line into 8.x. The 64-bit LLVM/Clang build of the translator itself is the clearest signal of intent: the tool has been modernised to sit comfortably in a current Windows toolchain rather than preserved as a period piece. That is unusual. Most single-author language tools that go quiet for years stay quiet.

The derivatives tell their own version of the story. bc9Basic forked BCX to add features its author wanted. MBC took the codebase somewhere BCX never went — building with Clang++ and G++ on 64-bit macOS and Linux, and with G++ on the Raspberry Pi — attacking the project’s single largest constraint, its Windows-only orientation. The Wii homebrew package pointed the translator at devkitPro. None of these are large projects, but together they demonstrate something about the translate-to-C architecture: because the output is portable C, retargeting the tool is a question of what the emitted runtime assumes, not of writing a new backend.

Current Relevance

BCX today is a live, narrow, well-maintained tool for a specific audience: people who want to write Windows software in procedural BASIC and get a native executable out. Releases arrive roughly monthly, the forum is active, and the documentation is current. It remains freeware and open source, and it remains Windows-first — every platform claim in the official material is a Windows claim, and nothing in the official documentation supports running the shipped translator natively elsewhere. (MBC is the route to macOS, Linux, and Raspberry Pi, and it is a separate project by a different author.)

It is worth being straight about the criticism. A SourceForge review argues that BCX-translated programs frequently fail to compile cleanly even on supposedly supported compilers without troubleshooting, and recommends QB64PE or FreeBASIC instead. That is one review of an outdated 2009 package rather than a survey, and it should be weighed accordingly — but the underlying tension it points at is real and structural. A translator that targets seven different C and C++ compilers is exposed to the differences between them in a way a self-contained compiler never is, and when something goes wrong the error message you get comes from the C compiler, phrased in terms of generated code you did not write. That is the price of the architecture, and readable output is the mitigation rather than the cure.

For anyone choosing a BASIC today, the honest comparison is with FreeBASIC and QB64 Phoenix Edition, both of which are self-contained compilers with cross-platform support and larger communities. BCX’s distinct pitch against them is unmediated access to the Windows C world: C headers used as-is, Win32 structures handled natively, generated C you can read and modify, and DLLs that drop into a C ecosystem. If that is what you need, nothing else in the BASIC family offers quite the same deal.

Why It Matters

BCX is a small tool that got one large architectural decision right. By refusing to compile and stopping at C source, a single hobbyist author built something whose output compiles on seven professional toolchains — inheriting whatever each of those compilers optimises, rather than competing with them — that followed the industry from 32-bit to 64-bit without a rewrite of any backend, and that could be retargeted to a game console and to Unix by other people without his involvement. Source-to-source translation is often treated as the cheap option. BCX is a twenty-seven-year demonstration that it can also be the durable one.

It is also a good case study in what keeps a language project alive. The technical work was necessary but not sufficient; what carried BCX through its quiet years was a community that had somewhere to gather, and what revived it was somebody providing a new somewhere when the old one closed. The 2019 restart is a straightforwardly social event — a hosting offer — that turned into a technical one.

And the self-hosting deserves its last word. A BASIC-to-C translator written in the BASIC it translates is a small, complete argument. Every criticism of BASIC as a language unsuited to serious programs has to contend with the fact that this particular BASIC has been used, for most of the project’s history, to build the compiler-shaped program that implements it.