~ / books / visual-basic-history / origins / vb-history-project-thunder / history v1
⚠ Viewing archived v1 · 3 h ago · [back to current]

Project Thunder — Ruby meets Embedded Basic (1989–1991)

Project Thunder — Ruby meets Embedded Basic (1989–1991)

By late 1988 Microsoft had Ruby — Cooper's drag-and-drop form designer — sitting inside the building with no obvious shipping vehicle. The Windows team had passed on shipping it as the Windows 3.0 shell. The Cooper-era engineers were on Microsoft payroll. The technology was real. It just didn't have a product around it.

What turned that into Visual Basic was a separate, unrelated internal project finally meeting Ruby.

Embedded Basic — a language with no IDE

Microsoft's other relevant project at the time was internally called Embedded Basic: a small, embeddable BASIC interpreter designed to be hosted inside applications as a macro and extension language. It was the latest descendant of the BASIC dynasty Microsoft had been compounding since 1975 — Altair BASIC, the 6502 and Z80 ports, GW-BASIC, QuickBASIC, BASIC PDS — built by the same in-house language group that had been refining Microsoft's BASIC tooling for the better part of fifteen years. Greg Whitten's name is the one most often attached to the era; the lineage is otherwise spread across a small group of Microsoft language engineers who don't show up much in retrospectives.

Where the earlier BASICs were standalone interpreters or compilers, Embedded Basic was deliberately not a product. It was a component: a language runtime and a host API designed to be linked into another application that wanted scripting. The strategic ambition behind it was what eventually became VBA (Visual Basic for Applications) — the macro engine that would later live inside Word, Excel, Access, and most of Office. In 1988–1989 the VBA destination was years away. Embedded Basic at that point was infrastructure with no shipping host: a language and an embedding contract, waiting for someone to pick it up.

That hosting model is what made Embedded Basic the right half of the eventual merge. Because it was already designed to be driven by a host application, slotting it into Ruby's form designer didn't require redesigning the language — it required Ruby to play the role of host, the same way Word would later. The constraints ran the other way too: Embedded Basic's semantics — the variant type, the late-bound function dispatch, the on-error / line-number heritage from QuickBASIC — are the semantics that show up in VB1 and that VB carries forward all the way to VB6. The BASIC half of "Visual Basic" is not new code written for the Thunder project. It is the BASIC dynasty, repackaged as a hostable runtime, and then dropped into a UI shell Microsoft happened to have lying around.

The Embedded Basic → VBA arc is also, in retrospect, the thread that saved BASIC inside Microsoft. When VB.NET broke the VB6 user base a decade later, the language that survived inside the company was not Visual Basic the standalone product — it was VBA, hosted inside Office, still running the same Embedded-Basic-descended runtime that started life looking for a vehicle in 1988. That story belongs to a later chapter. It is worth flagging here because it is the same code path: the embeddable BASIC that found Ruby in 1989 is the one still running in every Excel macro three decades later.

August 1989 — the merge decision

In August 1989, the call landed: take Cooper's Ruby form designer, swap its built-in command language for Embedded Basic, and ship the combined result as a development tool. Forest Moon's history of the project frames the moment plainly:

Visual Basic was conceived when Ruby met Embedded Basic for the first time in August of 1989.

The August date is the conception. The decision behind it is older. Earlier in 1989, Bill Gates had circulated an internal memo proposing that Microsoft pair Ruby with Embedded Basic — Gates having personally driven the Tripod acquisition the year before, and being the executive most invested in finding Ruby a destination after the Windows 3.0 shell rejection. The memo itself does not appear to survive in any public archive. What survives is the response to it.

The person tasked with turning the memo into an actual project was John Fine, a Senior Program Manager at Microsoft. In January 1989, Fine wrote the proposal for what became Visual Basic — the document that turned a Gates memo into a project plan engineers could execute against. Fine then became the program manager on Thunder itself. Forest Moon's account credits Fine alongside Scott Ferguson as the two people on point for responding to the Gates memo, with Fine on the program-management side and Ferguson on the development side.

Fine, more than Ferguson, is the administrative author of Visual Basic. Ferguson is the one whose first-person retrospective is publicly available, which is why most retellings centre him; Fine's role is substantively under-quoted because the proposal document itself has never surfaced. He appears in at least one Microsoft team photo from after VB 1.0 shipped, and beyond that the public record on him goes quiet. Whether the original January 1989 proposal still exists in any Microsoft archive is one of the genuine open questions of this chapter.

So the chain is: Gates memo (early 1989) → Fine's proposal (January 1989) → development work begins → Ruby and Embedded Basic meet for the first time in code (August 1989) → Project Thunder. That single architectural call — swap Ruby's command language out, swap Embedded Basic in — is the moment Visual Basic, as a concept, exists. Everything after it is execution.

Thunder — the codename that didn't quite die

The combined Ruby + Embedded Basic effort was internally given the codename Thunder. The convention at Microsoft was that internal codenames die at public launch — "Ruby" died when the product shipped as Visual Basic 1.0 in May 1991, the same way "Chicago" died when Windows 95 shipped. Thunder was supposed to follow the same pattern. It mostly did, on the marketing side. On the engineering side it left fingerprints.

VB internals from VB1 forward carry Thunder* symbol references. The runtime DLL ships with Thunder-prefixed exports. The Windows controls registry — the system table mapping window-class names to the controls that own them — uses Thunder* class names through the entire VB1 to VB6 lineage. If you've ever attached a debugger to a running VB6 application and seen ThunderRT6FormDC in a window-class string, that is a 1989 codename leaking through three decades of release engineering. The convention was that codenames die at launch. The reality is that once a name is baked into a class table, ripping it out costs more than leaving it in, and it stays for the life of the product line.

The Microsoft team

The Microsoft-side team that absorbed Ruby and Embedded Basic and turned them into a shipping product was small. The two names that consistently surface as the leadership pair are John Fine as program manager and Scott Ferguson as development lead and architect. Around them, the engineering bench named in surviving accounts includes Adam Rauch, Chris Fraley, and Brian Lewis — the role detail on each is genuinely thin in the public record beyond "engineer on the Thunder team."

Ferguson is the Microsoft-side figure whose voice survives in print. Years after VB shipped he wrote The Birth of Visual Basic, an essay on his own site at forestmoon.com that is the closest thing to a primary-source narrative of how Project Thunder came together inside Microsoft. Almost every retrospective that needs a Microsoft-side quote pulls from that essay, including this one. Worth flagging up front: it is Ferguson's first-person account of a project he led, written years after the fact, and the framing of who did what is necessarily his. Treat it as the Microsoft-side equivalent of Cooper's "father of Visual Basic" interviews — invaluable, primary, and partial.

Ferguson, deliberately, has called himself "Visual Basic's mom" in retrospective talks — a counterweight to Cooper's "father of Visual Basic" billing, and a gentle reminder that the parentage of this product was always shared. Cooper bought-and-built the form designer; Ferguson and his team built the integration that turned it into a development tool.

Fine is the Microsoft-side figure whose work is most under-quoted. The January 1989 proposal he wrote in response to the Gates memo is the document that turned Visual Basic from an idea into a project, and as program manager he was the administrative author of the thing through the Thunder phase. Fine appears in at least one surviving Microsoft team photo from after VB 1.0 shipped, and beyond that the public record on him is thin. If the original proposal document ever surfaces — internal Microsoft archive, personal papers, a leak — it would be the single most consequential primary source for this section.

Ferguson described the early days of grafting Ruby onto the Windows API like this:

We had only rudimentary skills at the start... to familiarize us with the internals of Ruby and teach us the "weirding way" of coercing the Windows USER APIs.

The "weirding way" line is widely quoted. What it tends to leave implicit is who taught them. Ferguson's own essay credits the Microsoft team with leaning hard on Mike Geary — Cooper's lead developer, on loan from the Cooper team during the integration — for exactly that role. Geary is the wizard the line is about. The Microsoft-side team learned the techniques for driving the Windows USER APIs from Ruby's form-designer surface from a Cooper-side engineer who had already spent eighteen months building the thing. That detail is the moment the section's editorial honesty has to land cleanly: the Microsoft team genuinely did the Thunder integration, and the Cooper-side wizard genuinely taught them how. Both things are true at once.

The technical shape — what Thunder actually was

By late 1990, Project Thunder was a Windows program that let you draw a form on a canvas, drop controls onto it from a toolbox, double-click a control to attach BASIC code to its events, and hit a button to compile and run. Four steps, end to end. The thing the trade press would later spend a decade calling rapid application development (RAD) already existed inside Microsoft's NDA boundary. It just didn't have a brand yet.

Behind those four steps were three architectural decisions made during the Thunder phase that shaped the next eight years of VB.

Form files — .frm

Forms were saved as plain text. A .frm file contained a property block describing the form and its controls — position, size, caption, font, and so on — followed by the BASIC code attached to each control's events. No binary blob, no proprietary container; just human-readable text a developer could open in a text editor.

The format was unusual for the era. Most Windows tools of the period saved their UI work as binary resource files. Microsoft chose text deliberately, primarily to keep .frm editable outside the IDE for tooling and recovery purposes. The side-effect — a UI format that diffed cleanly in source control — was incidental at the time and load-bearing later. The .frm format survived, essentially unchanged in its structural shape, through VB6 and is still readable by tooling thirty-five years later.

The runtime DLL — VBRUN100.DLL

VB programs did not compile to standalone Windows executables. They ran inside a Microsoft-shipped runtime DLL: VBRUN100.DLL for VB1, VBRUN200.DLL for VB2, VBRUN300.DLL for VB3, and so on through the version line. The compiled VB application was effectively a tokenised script plus form data hosted by the runtime — the BASIC code was not native x86 machine code but an interpreted intermediate form that the runtime executed. (The compiled-vs-p-code question becomes a real shipping switch in VB5 and VB6; for the Thunder-era product it was interpretation, full stop.)

Two consequences fell out of that decision. The first was that VB binaries were small — the compiled application carried no language runtime of its own, because the runtime lived in the DLL the user was assumed to already have. The second was that every VB application was coupled to the exact runtime version it was built against. Shipping a VB1 application meant shipping VBRUN100.DLL alongside it, or trusting that the user already had it installed. The deployment story this created — the runtime-versioning, the shared-DLL dance, the install-program-bundles-the-runtime convention — became its own decade-long subgenre of Windows software engineering. That story belongs to a later chapter; the architectural decision belongs here.

VBX — Visual Basic Extension controls

The third architectural decision was VBX: a C-language plug-in interface that let third parties ship new controls into the form designer. A VBX was a Windows DLL with a specific set of exported entry points; drop one into VB's controls directory and it appeared in the toolbox alongside Microsoft's stock controls, available to drag onto a form like any other.

The VBX interface itself was designed by Mike Geary at Cooper Software during the Ruby project, before the Microsoft acquisition's integration work began. Geary's own resume credits him with designing "the VBX interface that millions of developers used to build and embed custom controls." The Microsoft-side Thunder team finalised the format and shipped it; the design was Cooper-side. Same pattern as the form designer itself: the architecture came from Cooper, the productisation came from Microsoft, and both halves are real.

What VBX enabled was a market. Because the format was a C-callable DLL contract, anyone with a C compiler and the spec could build a control and sell it. Ferguson's later one-line summary of the result:

A whole new cottage industry was born as a side effect.

By VB3 that cottage industry — Sheridan, MicroHelp, Crescent, Pinnacle, FarPoint, dozens of others — was a substantial slice of the Windows software economy in its own right, with its own conferences, magazines, and small-vendor ecosystems. The full VBX-to-OCX migration story belongs to a later chapter alongside VB4 and the COM transition. What matters for section 04 is that the third-party control market existed because of an interface decision a Cooper-side engineer made before Microsoft owned the code.

Why the public name became "Visual Basic"

The product needed a name that wasn't Thunder and wasn't Ruby. Microsoft's choice was deliberate on both halves:

  • "Basic" preserved brand equity from fifteen years of Microsoft BASIC. The customer base for QuickBASIC and BASIC PDS was the customer base Microsoft most wanted to bring along.
  • "Visual" signalled the form designer — the new thing.

The name is honest about the product: it is BASIC, with a visual front end. It also implicitly set up the marketing pitch Microsoft would deliver at launch: the visual part is what's revolutionary, the BASIC part is what you already know.

The launch itself, and the propaganda Microsoft built around it, is the next section.

Sources