Visual Basic was not designed as a single whole. It is the assembly of two unrelated projects: a form generator bought from an independent designer, and a Basic engine written for a database product. Their marriage was decided by an internal memo in August 1989. This article traces the genealogy — and what it left in the structure of the executables.

1988: Ruby, a shell that would not replace the shell

In 1988 Alan Cooper created a visual programming language codenamed Ruby. It was not a development environment but a "shell construction set": a tool for composing an interface by drag and drop, intended to replace the Windows shell.

Cooper demonstrated Ruby to Bill Gates, who judged that the innovation would have a "profound effect" on Microsoft's product line. The company bought Ruby, with the initial intention of shipping it with Windows 3.0.

That is not what happened. Microsoft decided against releasing it as an end-user shell and turned it into a professional development tool instead. Windows 3.0 shipped with Program Manager, and Ruby was left without a purpose.

Embedded Basic, engine of a database project

At the same time, another team was developing Embedded Basic — EB — a language engine intended for inclusion in a database product codenamed Omega. EB was not a product but a component, designed to be embedded in a host application.

The future product's name already existed. In January 1989 John Fine wrote a proposal for a language product called "Visual BASIC". The name therefore preceded the decision to merge the two technologies by several months.

August 1989: the memo

Bill Gates sent a memo to management in the Business Languages group: find a way to mate Ruby with EB. The meeting took place in August 1989. The project was codenamed Thunder.

The first-hand account of that period was published by Scott Ferguson, the project's development lead and architect. He names the team: Adam Rauch as program manager, Chris Fraley as the first dedicated VB developer, Brian Lewis for the EB team, Rick Olson on testing, Nevet Basker on product marketing, Brian Overland on documentation, and Michael Geary as a consultant on Ruby. What was meant to be a six-month side effort became an eighteen-month full product.

What Ruby brought

The form designer, drag and drop, and the notion of a control carrying properties and events.

Plus a dynamic extension mechanism: third-party controls loaded at run time.

What Embedded Basic brought

The interpreter, the Basic syntax, memory and type management.

An engine built to be embedded, and therefore driven from outside — which is what the form designer would do.

1991: Visual Basic 1.0

The product was presented in May 1991 at Windows World. The custom control mechanism inherited from Ruby was given the .VBX extension, suggested by developer Lee Acton; it would later become OCX, then ActiveX.

Alan Cooper would remain known as the "father of Visual Basic", a title he never claimed: he did not care for Basic, and the product that shipped was not the one he had designed.

Chronology

1988
Ruby · Alan CooperVisual form generator, designed as a shell for Windows. Bought by Microsoft after a demonstration to Bill Gates.
Jan 1989
The name before the productJohn Fine writes a proposal for a language product called "Visual BASIC".
Aug 1989
The memo · codename ThunderBill Gates asks the Business Languages group to mate Ruby with the Embedded Basic engine written for the Omega project.
May 1991
Visual Basic 1.0Presented at Windows World. The .VBX extension for custom controls is suggested by Lee Acton.
1997
Visual Basic 5Machine code compilation added alongside P-Code. The executable format splits in two.
1998
Visual Basic 6Last version of the line. The format it fixed has not changed since.
2002
Visual Basic .NETA different language on a different platform. MSIL replaces P-Code.end of the VB6 line

The seam is still in the binary

Thirty-five years after the memo, the graft remains legible. A Visual Basic 6 executable does not contain a homogeneous whole: it contains the description of the forms and their controls on one side, and compiled code on the other. The two worlds did not undergo the same treatment, and that is the direct legacy of their separate origins.

Ruby's legacy

  • Forms, controls, layout
  • Control names and property values
  • Stored as described data, not translated into instructions
  • And so they survive compilation

Embedded Basic's legacy

  • Procedure bodies, expressions, loops
  • Local variable names, constants, enumerations
  • Translated into P-Code or x86 depending on the compilation mode
  • What compilation degrades or removes

That structural reason is why a Visual Basic decompiler returns a faithful interface and partial code, rather than the other way round. What comes back depending on the compilation mode is covered in P-Code or native code and in from P-Code to MSIL; the tooling built around the problem is listed in a history of Visual Basic decompilers.

VBReFormer's measured coverage, function by function and instruction by instruction, is published with its denominators: 1,153 documented correspondences. The free edition indicates within seconds what a given binary holds.