~ / books / visual-basic-history / origins / vb-history-alan-cooper-and-tripod / history v1
⚠ Viewing archived v1 · 5 h ago · [back to current]

Alan Cooper and Tripod (1985–1988)

Alan Cooper and Tripod (1985–1988)

While Microsoft was iterating its DOS BASIC compilers through the late eighties, a California developer named Alan Cooper was doing something none of them were: building a way to draw a Windows program instead of typing it.

The architect who became a developer

Cooper had originally trained as an architect before moving to software, and the framing stuck. He talks about software the way an architect talks about buildings — as a designed thing serving a human purpose, not as a stack of features. By the early eighties he was working as a developer in California, a self-employed consultant on the small-systems end of the industry. The work that mattered most for what came next was on SuperProject, a project-management tool that shipped in 1983 — Cooper was the original developer of an early version, sold the rights, and watched it become a Computer Associates product. That sale gave him capital and time. He used both to build his own thing.

After Microsoft shipped Windows, Cooper started a project he called Tripod. His own framing for it was specific and worth quoting: not a programming language, not an application, but a "shell construction set" — a tool to build the shell you wanted. The shell was the killer concept; the form designer was how you built it.

That word — shell — does not carry the same load in 2026 that it did in 1988, so it's worth pinning down. In late-eighties Windows, the shell was the program a user ran on top of Windows to get to everything else. Windows 1.x and 2.x shipped with MS-DOS Executive as the default shell — a file-list-and-menu thing that nobody loved. Replacing it was a live commercial proposition: Norton Desktop, hDC NewWave, and Wintools all later shipped as Windows-shell replacements on the same premise. Cooper's bet was that end users would build their own shells if you gave them a tool that did not require a C compiler.

The way you built a shell in Tripod was by drawing it. Forms, buttons, lists, drag-and-drop controls assembled on a canvas. The runtime carried the Windows message loop; you wired up behaviour by attaching code to the events the controls raised. That event model — the Form_Load / Button_Click pattern that every VB developer for the next thirty years would recognise on sight — was already in Tripod, by name, before Microsoft had ever seen it. Tripod itself was written in C, around 25,000 lines of it, targeting the Win16 API as it stood in Windows 2.x.

The significance is hard to overstate from a 2026 vantage. In 1987–1988, building a Windows program meant the Windows SDK, a C compiler, and a roughly thousand-line WinMain skeleton with a hand-rolled message loop before you drew your first pixel. Tripod skipped the compiler and the message loop and the SDK. You drew the program. It ran.

One technical fact about Tripod is widely missed in retrospectives, and it changes the frame: Microsoft did not ship Tripod. After the acquisition, Cooper threw the original 25,000-line Tripod codebase away and the team rewrote the project from scratch over 18 months, delivering a golden master to Microsoft in early 1990. The shipped code was Ruby, not Tripod. The conceptual lineage runs through Tripod; the bytes do not. That distinction matters for anyone counting which lines of which codebase ended up inside Visual Basic 1.0 — none of Tripod did, directly. What Microsoft bought was the design, the team, and the proof that it could work.

March 1988 — the demo to Bill Gates

In March 1988 Cooper showed Tripod to Bill Gates personally. The demo took place on Microsoft's Bellevue / Redmond campus, with Gates and a group of Microsoft people in the room — Cooper has consistently called them Gates' retinue in retellings, which both gives the moment its texture and signals that the people responsible for not having built something like Tripod were standing right there as Gates saw it for the first time.

What Gates actually saw was not a slide deck or an architecture diagram. Cooper showed him the form designer working: dragging controls onto a canvas, wiring up behaviour, and — the moment that mattered — running the result as a real Windows program. In 1988 nobody else in the industry was doing that for Windows. Gates had spent the back half of the decade watching his own teams build Windows applications the hard way, in C against the SDK. He was looking at the alternative.

Cooper's account of Gates' reaction has been quoted in multiple later interviews:

It blew his mind. He had never seen anything like it. At one point he turned to his retinue and asked, "Why can't we do stuff like this?"

The "Why can't we do stuff like this?" line has become the most-quoted four words in VB's pre-history, and for good reason. It captures the moment Microsoft committed to buying the technology rather than building it — and it captures something else too. Gates was not asking it of Cooper. He was asking it of his own people, in front of Cooper, as an accusation. The subtext is the part the line is remembered for forty years later: Microsoft hadn't built it, and someone outside Microsoft had.

Gates didn't ask for a follow-up meeting. He asked for a price.

Microsoft bought Tripod from Cooper in 1988. The deal terms have not been publicly disclosed in detail. Gates is widely reported to have framed the acquisition internally as something that "would have significant impact across Microsoft's entire product line" — a line that, given what Visual Basic became, has aged unusually well for an executive's pre-product framing. The structure of the deal kept Cooper's team intact under the Cooper Software banner as outside contractors building the rewrite for Microsoft, rather than absorbing them as Microsoft FTEs. That choice — keep the team together, keep them outside, ship in eighteen months — is the part that made the rewrite possible.

Cooper himself sold rather than ship Tripod commercially under his own banner, and he has been candid in retrospect about the trade-off:

Had Ruby gone to the market as a shell construction set it would have made millions of people happier, but then Visual Basic made hundreds of millions of people happier.

That is the practitioner-economist version of the same point this section keeps coming back to. Microsoft did not invent the form designer. What Microsoft brought to the form designer was distribution at a scale Cooper could not have approached on his own — and Cooper, asked to make the trade, took the cheque.

The team

The team Cooper had built around Tripod went with the deal, working under the Cooper Software banner from 1988 to 1990 while building Ruby for Microsoft on contract. Four names appear in the surviving accounts:

  • Mike Geary — lead developer for Ruby. The most consequential of the four after Cooper himself. Geary designed the VBX interface, the C-language plug-in architecture that opened the door to the third-party custom-control market that defined VB economically through the nineties. He is also the source of two pieces of programming vocabulary that survive in the language we still use: "fire an event" is his coinage, and the UI components that everyone now calls controls were called "gizmos" in the Ruby-era source — Cooper had wanted "waldos" (after Heinlein's remote manipulator arms) and Geary couldn't make sense of the name. Geary is reachable in 2026 — active on LinkedIn and Stack Overflow, with a personal site at geary.com — and his role earns its own companion post in this series.
  • Mark Merker — programmer on the Tripod / Ruby team, 1988–1990. No public post-Microsoft trail confirmed.
  • Gary Kratkin — programmer on the Tripod / Ruby team, 1988–1990. No public post-Microsoft trail confirmed.
  • Frank Raab — programmer on the Tripod / Ruby team, 1988–1990. No public post-Microsoft trail confirmed.

That last point is part of the editorial story this book is trying to tell, so it is worth marking explicitly: three of the four engineers who built the form designer that became the visible half of Visual Basic have effectively vanished from the public record. No interviews, no retrospectives, no recoverable post-Ruby career trails. They appear in named-roster references in Cooper's later interviews and Geary's own resume, and almost nowhere else of substance. By the time anyone in the industry started to write seriously about where VB came from, three of its co-authors were already gone from the searchable web.

Inside Microsoft, the project was rechristened Ruby.

Aside: the other Ruby

Aside, because everyone reading this is about to ask: no, this is not the same Ruby as the programming language. Pure coincidence. Microsoft's Ruby was a Windows shell tool written in C, internal codename only, and the name died inside the company when the product shipped as Visual Basic in 1991. The Ruby language was created in Japan by Yukihiro "Matz" Matsumoto, with development starting in February 1993 and the first public release in December 1995 — five years after Microsoft's Ruby had already been absorbed into VB. Matz has said in interviews that he and his collaborator Keiju Ishitsuka picked the name in a chat, riffing on Perl's gem-naming tradition, and that he was unaware of Microsoft's internal codename. Two unrelated projects, both named after the same gemstone, separated by half a decade and the Pacific.

Back to Microsoft's Ruby.

Ruby was supposed to be the Windows shell

The company's first plan for Ruby was not Visual Basic. It was not even a development tool. The plan was to ship Ruby as the shell for Windows 3.0 — the program a user would see when Windows booted, replacing MS-DOS Executive. That is a genuinely consequential plan. Windows 3.0, when it shipped in May 1990, was the release that finally made Windows a mass-market operating system. Whatever shipped as its shell would have been used by tens of millions of people on first boot.

The Windows team passed on it.

Cooper himself has been careful in retrospect not to claim insider knowledge of why. "The reasons," he has said in multiple later interviews, "I was not privy to." That is honest, and it is a quote worth preserving as his framing — but the second-hand accounts in Forest Moon's The Birth of Visual Basic, Retool's Something Pretty Right, and the CHM Fellow material fill in enough of the rationale to make a reasonable reconstruction.

Three threads, none of them flattering, and all probably true at once:

  • The Windows team had its own ideas. Win 3.0's shell was already on its way — it shipped with Program Manager (the icons-in-groups launcher) and File Manager (the file browser). Neither was a "shell construction set" by Cooper's definition; both were finished products designed by the Windows team. Replacing the Windows team's own shell with an outside team's shell, on a flagship release, was a political non-starter regardless of the technical merits.
  • A user-facing shell is not a developer-facing tool. Ruby's whole pitch — the user assembles their own shell out of drag-and-drop controls — was a developer's pitch in user's clothing. Microsoft's product organisation in 1989 was not structured to ship a tool that asked end users to build their own desktop. Microsoft Office's "we ship the desktop, the user runs the apps" model was already the company's commercial centre of gravity.
  • Internal politics. Cooper's team was a Cooper Software contract crew, not Microsoft FTEs. Asking the Windows division to make a Cooper-Software product the face of Windows 3.0 was a hard ask under any circumstances. The acquisition had been driven personally by Bill Gates, which made it a political artefact at the divisional level — something to be absorbed and redirected rather than carried into the marquee release.

Whatever the actual mix, the outcome is the part that matters: the Windows team said no, and Microsoft now had a tool with no destination. So Microsoft now had:

  • A drag-and-drop form designer it had paid for.
  • A team of outside engineers it had hired.
  • No obvious place to put any of it.

What it did with that situation is the subject of the next section — and it required pairing Ruby with an unrelated internal project that, on its own, was also going nowhere.

Sources