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. The specific architectural influence Cooper names in his own retrospectives is Christopher Alexander, whose 1964 book Notes on the Synthesis of Form Cooper found in his high school library at fourteen. The book's framing of design as problem-solving (synthesis of form to fit a context) is what Cooper carried into software. He uses the term "Alexandrian design" for his own approach in his published interviews. 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 and 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 and 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

The route to Gates was not direct. By late 1987 Cooper had been showing Tripod to a sequence of software publishers (Adobe, Lotus, others) hoping one of them would take it to market. Each one said the same thing: this is really cool, why don't you show it to Microsoft? Cooper resisted at first, on the obvious ground that Microsoft was busy building its own thing and Tripod would land as a competitor. Eventually he gave in.

His Microsoft contact was a man he calls Glen in his published retrospectives, an ex-Digital-Research colleague who had moved to Microsoft's sales team. Cooper asked Glen for an audience with Gates. Glen called back a couple of weeks later: not with Gates, but with one of his guys.

The screening demo Cooper gave was to Gabe Newell, the same Gabe Newell who would later leave Microsoft in 1996 to co-found Valve. Newell was a Microsoft staffer in 1988, working on Windows. Cooper had a half-hour scheduled. Five minutes in, Newell pushed his chair back and said, "Bill's got to see this." He did not need to see the rest of the demo to know what he was looking at.

Cooper went home and coded for a month, by his own account "like a crazed coding weasel," adding features to the prototype before the Gates meeting. The follow-up landed in March 1988, in a boardroom on Microsoft's Redmond campus with Gates and about a dozen Microsoft people in the room. Cooper has consistently called them Gates' retinue in retellings.

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.

Two exchanges from that demo are quoted across all of Cooper's later retrospectives. The first, when Cooper showed Gates the sprite animation Microsoft's own teams had not yet figured out how to do:

Gates: "How did you do that?" Cooper: "It's magic, Bill."

And the second, when Gates turned to his own team and made the line every retrospective ends up quoting:

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 the conventional read of it is that Gates was simply impressed. That read is incomplete. Cooper's own retrospective on the moment, given to Hansen Hsu of the Computer History Museum in 2017 and published in IEEE Annals of the History of Computing in 2020, sharpens it:

I had no idea how wrong that was, but I learned later. ... what he was doing was he was making all those guys at the table hate me. You know? Because, you know, I showed them up really badly. Alan Cooper, IEEE Annals oral history, p.107.

The line was a public humiliation of Gates' own team, delivered in front of the outsider who had built the thing they had not. The same team Gates dressed down in that boardroom would, eighteen months later, find ways to ensure Ruby was kicked out of the Windows 3.0 build. The "Why can't we do stuff like this?" moment is real, and it is the moment Microsoft committed to buying Tripod. It is also the moment Cooper, retrospectively, sees as the seed of the political damage that would eventually orphan the product inside Microsoft.

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 and Ruby team, 1988 to 1990. No public post-Microsoft trail confirmed.
• Gary Kratkin, programmer on the Tripod and Ruby team, 1988 to 1990. No public post-Microsoft trail confirmed.
• Frank Raab, programmer on the Tripod and Ruby team, 1988 to 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 was careful in retrospect, for many years, not to claim insider knowledge of why. "The reasons," he said in earlier interviews, "I was not privy to." That hedge is honest as far as the politics outside his own meetings went. The 2020 IEEE Annals oral history, published years after those earlier interviews, is the place where Cooper finally put the kill mechanism on the record from his own perspective:

Microsoft was fighting with IBM, who was their big patron at the time. And Windows was actually not a strategic product for Microsoft. OS/2 was the strategic product, and it was for IBM, their client, and it was getting all the calories within the organization, and it was the B-team was working on Windows. ... so the shell construction set, they said, "Look, you have to be able to be identical to the OS/2 shell." And I said, "Well, look, you can build the OS/2 shell from scratch in about ten minutes using Ruby." They said, "Is it keystroke for keystroke identical, and pixel for pixel identical?" And I said, "Well, it's close!" Well, okay, that was just enough of a beachhead that they could point to it and say, "This won't work." And so they kicked it out of the build. Alan Cooper, IEEE Annals oral history, p.107.

Read as a primary-source account, what happened is plain. The OS/2 partisans within Microsoft (the team building the strategic product for IBM) demanded that Ruby be bit-perfectly identical to the OS/2 shell as the shipping criterion. The demand was the kill. No shell construction set could plausibly meet pixel-for-pixel parity with a finished GUI shell, and the OS/2 team knew it. The criterion existed to disqualify Ruby and to protect the OS/2 team's own UI work from being made redundant by an outsider's tool inside the same company. The Windows team's own Program Manager and File Manager shipped on Windows 3.0 in May 1990; Ruby did not.

Cooper flew back up to Seattle to ask Gates to sell Ruby back.

I flew back up to Seattle and met with Bill and I said, "Will you sell it back to me? 'Cause I'll release it myself. I'll publish it myself as a shell construction set for Windows." And he thought about it and he said, "No." I had no leverage, and he figured he could do something with it. So I came back home and I tried to start a company, and of course, I was seriously nondisclosured. Alan Cooper, IEEE Annals oral history, p.107.

The buy-back attempt is the part of the story rarely told. Cooper, watching the OS/2 partisans suffocate his work inside Microsoft, tried to take it back. Gates declined, kept the asset, and locked Cooper out via the original NDA. For the next two years Cooper sat outside while Microsoft figured out what to do with a tool he could no longer touch.

What Microsoft did with the 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

• IEEE Annals of the History of Computing, Oral History of Alan Cooper (Hansen Hsu interviewer, interviewed 2017-03-13 in Petaluma CA, published October-December 2020 issue, 19 pages). DOI 10.1109/MAHC.2020.3033744. Primary source for the Glen-broker / Gabe-Newell-screening / Gates-demo sequence, the "It's magic, Bill" exchange, Cooper's retroactive read on the Gates moment, the OS/2 rejection criterion, and the buy-back attempt.
• Computer History Museum, Archive Collections, 2017 CHM Fellow Awards, Alan Cooper Video, catalog 102740201. Primary source for Cooper's "shell construction set" framing and the Glen / bank-teller motivation story.
• Computer History Museum, 2017 CHM Fellow Alan Cooper: Father of Visual Basic (editorial blog summary).
• Computer History Museum, Alan Cooper profile.
• Wikipedia, Alan Cooper (software designer).
• Forest Moon, The Birth of Visual Basic.
• Retool, Something Pretty Right: A History of Visual Basic.
• Red Gate Simple Talk, Alan Cooper: Geek of the Week.
• Socket3, Visual Basic: Early Beginnings.
• Wikipedia, Ruby (programming language).