FBSL

FBSL - Freestyle BASIC Script Language - is a Windows scripting language that refused to stay a scripting language. It began in 2001 as a personal tool for replacing batch files, grew into a full BASIC dialect with classes and namespaces, learned to compile itself into standalone executables, and eventually gained something almost no other BASIC has offered: the ability to drop verbatim Intel-syntax assembly and ANSI C into the middle of BASIC source and have all three compiled together at runtime.

The “Freestyle” in the name is a statement of method. Where most language designers pick a syntactic tradition and stay inside it, FBSL borrowed openly from Visual Basic, QBasic, PHP, Pascal and C++ and let programmers mix the results. It is a language with more than one way to say almost everything, built by people who considered that a feature.

It is also, today, effectively dormant. The project was closed source, tied to a single vendor’s operating system, and hosted at a domain that has since lapsed. What remains is a body of archived documentation, mirrored installers, a Rosetta Code category and the memory of a small, unusually devoted community.

History & Origins

A build engineer’s problem

FBSL’s origin story is unusually well documented, because Guillemin wrote it out himself on the project’s own site.

In 2001 he was, in his own words, working “for a big company” - identified in some community accounts as the French software house BVRP - where he was responsible for producing around thirty software masters in several languages, including English, French, Hebrew and Chinese. The work was highly repetitive: dispatching files, verifying directory trees, checking disks, rebuilding the same installer with different resources. Batch scripting, he wrote, was “not totally sure” for the job - it left him unable to guarantee that no files or directories had been missed. So he wrote several purpose-built tools in C instead, and ended up with a scattering of executables sitting on a server.

The fix was to unify them behind a single script interpreter. FBSL 0.1, which by his account dates from April 2001, exposed fifteen native commands. Guillemin put it on the web to see whether anyone else had the same problem. People did.

BCX, LCC and a useful neighbour

The implementation history is a small monument to the freeware Windows toolchain of the early 2000s. FBSL was originally developed under LCC-Win32, the free C compiler by Jacob Navia; the official site later recorded that development had moved to MinGW/GCC. Community accounts add that the engine itself was written first in BCX, a BASIC-to-C translator, because writing BASIC that emitted C was faster for Guillemin than writing the C directly.

If that account is right, it shaped everything that followed. FBSL would be a BASIC whose own engine was bootstrapped through a BASIC-to-C translator into a C compiler - a language built with the same kind of pragmatic layering it would later offer its users.

Around 2002 Guillemin is reported to have met Mikhail “Mike” Lobko-Lobanovsky, a developer skilled in assembly and C who was also active in the BCX community. Lobanovsky became a long-term collaborator and, per the project’s own team page, the author of FBSL’s GUI grammar and of the FBSL RAD. That page also credits Mehdi Bouaziz as co-author and author of the version 3 engine, Victor Michel as a version 2 co-author, and Helena Cavagna as author of the first FBSL IDE.

From script to environment

The capability list grew steadily through the early 2000s:

• FBSL2EXE (reportedly around 2002) embedded a script into a standalone executable, so scripts could be shipped as programs
• FBSL became available as a STDCALL flat-model DLL, letting Visual Basic, C and Delphi applications call into FBSL code - a capability the project advertised on its 2006 homepage
• COM support meant FBSL scripts could drive COM-automatable applications such as the Microsoft Office programs
• A GUI layer turned a build-automation scripter into a tool for writing Windows applications
• Work on the version 3 engine moved the language from a largely line-oriented script model to proper multi-line program structure

By the time v3.2.7.2 was published - the project’s download page dated it 22 November 2006 - FBSL had classes, namespaces, user-defined types and unions, dynamic arrays, and a 650-page CHM reference manual.

Design Philosophy

Every syntax at once

Most languages that borrow do so quietly. FBSL advertised it. The project’s own description lists its inspirations as Visual Basic, QBasic, PHP, Pascal and C++, and calls the result “a sort of hybrid language hence the ‘Freestyle’.” In practice this meant a programmer could use BASIC keywords, C-style operators and PHP-flavoured string handling in adjacent lines, and the parser would accept all of it.

This is not a design most language theorists would endorse. It is, however, exactly what a self-taught Windows programmer in 2004 with a decade of accumulated habits from three different languages actually wanted.

Windows, deliberately and completely

FBSL never pretended to be portable. It was designed for Win32 and built its identity on how directly it could reach the platform: raw Windows API calls, COM objects, third-party DLLs, memory-mapped files, sockets and threads, all exposed as native layers rather than through wrapper libraries.

Per the project’s own documentation across its lifetime, the supported target was 32-bit Windows: the 2006 site named Windows 95 SR2 through Windows Vista, the 2009 site Windows 98 through Vista, and later listings reportedly extended the range to Windows 7 on both 32- and 64-bit editions. The 2006 site also stated that FBSL was “compatible with, and fully functional, under Linux WINE”. Community sources additionally claim it runs under WINE on other hosts and under ReactOS; those are compatibility-layer reports rather than native ports, and are best verified against a specific build before being relied on.

Small, self-contained, deployable

FBSL’s interpreter was distributed as a small single executable with no runtime to install alongside it; contemporary reviews put compiled standalone GUI applications at around 90 KB. A script could be run directly, compiled into a standalone EXE, or - unusually - decompiled back out of one. The project also offered password protection on compiled executables to deter that decompilation when applied to your own output.

The insistence on self-containment ran through the whole product. The RAD environment and IDE were advertised as being written entirely in FBSL with no external dependencies, which served as both a dogfooding exercise and the project’s headline argument that the language was serious.

Key Features

The type model

FBSL v3 exposes five underlying data types:

On top of these sit user-defined types and unions, dynamic arrays and COM objects. Variables are dynamically typed by default in the scripting tradition, with Option Explicit available for programmers who want declarations enforced.

Classes and namespaces

FBSL v3 described itself as “semi-OOP” - it has classes with public and private sections, constructors and methods, and namespaces to contain them, without the full inheritance machinery of a language designed around objects. The example the project used on its own homepage:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#AppType Console
#Option Explicit

NameSpace Test

  '// 1st class...
  Public Class CEN
    Private: s
    Sub Initialize(s_)
      s = s_
    End Sub
    Public: Method Hello()
      Return "Hello " & s
    End Method
  End Class

  '// 2nd class...
  Public Class CFR
    Private: s
    Sub Initialize(s_)
      s = s_
    End Sub
    Public: Method Hello()
      Return "Salut " & s
    End Method
  End Class

End NameSpace

Dim H As New Test.CEN("Gerome"), I As New Test.CFR("Mehdi")
Print H.Hello()
Print I.Hello()
Pause

Note the '// comment marker - simultaneously a BASIC apostrophe and a C++ double slash. That single token is the whole design philosophy in miniature.

Native layers

Rather than a package ecosystem, FBSL shipped functionality as built-in layers. The 2006 feature list names COM, Win32 API, clipboard, string, maths, regular expressions, dynamic arrays, memory-mapped files, LZO compression, sockets, threads and console. For a language with no package manager and a small community, bundling everything was the only workable answer.

DynAsm and DynC

The most distinctive feature arrived in the later v3.x line and is the reason FBSL is remembered at all by people outside the BASIC world. FBSL gained a Dynamic Assembler and a Dynamic C JIT compiler layer, allowing verbatim Intel-syntax assembly and ANSI C to be interleaved with BASIC in a single source file. Per the project’s own description, FBSL remained an interpreter, and DynAsm and DynC converted their listings to native machine code in memory at application start, alongside the FBSL bytecode they were meant to interact with.

This collapses a boundary that most language ecosystems treat as fixed. In C you drop to assembly through asm blocks; in BASIC you normally reach C through a DLL and a foreign-function interface. FBSL let a script-level BASIC program carry a hot loop written in assembly and a helper written in C in the same file, with no separate build step and no external toolchain. In a language explicitly designed around mixing syntaxes, it is the logical endpoint - and it made FBSL, for a while, one of the few interpreted BASICs where a performance-critical inner loop did not have to leave the source file.

Published claims about how much faster this made FBSL programs generally came without stated benchmark methodology, baseline or hardware, so the honest summary is architectural rather than numerical: DynAsm and DynC removed the interpreter from the path for the code placed inside them, and how much that was worth depended entirely on the workload.

Evolution

FBSL’s development falls into three fairly clean phases.

2001-2002, the tool. Line-oriented scripting, a small command vocabulary, a single author, and a problem domain no wider than build automation - the pre-v2 releases.

2002-2006, the language. A team forms. The v2 and then v3 engines are written, multi-line structure arrives, GUI and COM support turn it into an application language, and the DLL interface lets other languages embed it. The RAD and IDE, written in FBSL itself, become the flagship demonstration. This is FBSL’s most active period, with a busy community forum - Invision Power Board in the mid-2000s, later phpBB, which the 2009 site described as “very active” - along with extensive documentation and regular releases.

Post-2006, refinement and decline. The 3.x line continued for roughly a decade. DynAsm and DynC were the major additions, and the platform target crept forward through successive Windows releases. But the ground was shifting: the free Windows toolchain that FBSL grew out of was being replaced by .NET and, later, by cross-platform ecosystems that a Win32-only closed-source BASIC could not follow.

The official forum was still being archived into 2012, and public activity thins after that. The last well-documented development is Mike Lobanovsky’s v3.5 RC3 build, discussed on the retro BASIC forum at allbasic.info in September 2016, which added console primitives such as InKey() and WaitKey() and demonstrated a near-verbatim port of a Microsoft QuickBASIC 4.5 sorting demo - a fitting final act for a project that had always been about making old code and new code live in the same file.

Current Relevance

FBSL is dormant, and the manner of its dormancy is instructive. The fbsl.net domain no longer belongs to the project; it now serves an unrelated fitness site. The forum that anchored the community is gone. Because the source was never publicly released, there was no repository for anyone to fork when the maintainers moved on.

What survives is scattered but real:

• The Rosetta Code FBSL category, with solutions across dozens of tasks, which is now the most convenient way to read FBSL code
• Archived copies of the official tutorial and CHM documentation
• Mirrored installers of 3.x builds on software archive sites, of the usual uncertain provenance
• Forum threads on BASIC community sites, particularly around the v3.5 release candidates

Anyone wanting to run FBSL today faces the same constraints it always had - it is a 32-bit Windows program - plus a new one: the binaries available are unofficial mirrors rather than vendor downloads.

Why It Matters

FBSL is not an important language by any conventional measure. It had no institutional backing, no standard, no documented commercial deployment beyond its author’s own work, and a core team small enough to be named individually on the project’s own homepage. But it is a genuinely interesting artefact for three reasons.

It is a clear case of a tool escaping its purpose. FBSL 0.1 was fifteen commands written to stop one person from maintaining a scattering of separate C utilities. Fifteen years later the same project had classes, namespaces, COM automation, a self-hosted IDE and a JIT assembler. Very few languages have a documented, first-person account of that trajectory written by the person it happened to; FBSL does, and it is worth reading precisely because it is so ordinary in its motivations.

It took syntax pluralism further than almost anyone. Most multi-paradigm languages mix paradigms while holding syntax constant. FBSL mixed the syntaxes themselves, and then extended the same logic all the way down through DynAsm and DynC to assembly and C. Whether that is good design is arguable. That it was carried out consistently, to its logical conclusion, is not.

It is a case study in why closed source kills small languages. FBSL had an engaged community, thorough documentation and a decade and a half of continuous development. What it did not have was a public repository. When the maintainers stopped and the domain lapsed, there was nothing left to inherit - no way for a successor to pick up the engine, port it off Win32, or even keep an authoritative build available. Contemporaries with far fewer users and far worse documentation are still installable today because their source is on a public host. That difference, more than any technical decision, is why FBSL is a historical entry rather than a living language.