The Inside Story of Visual Basic, the Programming Language That Made Windows Possible
Software designer Alan Cooper explains why they call him the ‘Father of Visual Basic’
Since my interaction design firm, Cooper, has had new owners now for more than two years, it’s not surprising to find that some of my more personal Web postings have been quietly removed from Cooper dot com. One casualty was an essay I originally wrote and posted in 1995 that tells the origin story of Visual Basic. I am reposting it here with slight updates from the original piece I wrote 25 years ago.
Mitchell Waite called me the “father of Visual Basic” in the foreword to what I believe was the first book ever published for Visual Basic (VB), called Visual Basic How-To (now in multiple editions, published by The Waite Group Press). I thought the appellation was an appropriate one and frequently use the quoted phrase as my one-line biography.
During the 1980s, my business consisted of inventing software and then selling it to publishers. In 1986, I adopted Microsoft Windows as my platform of choice. Not only did it do all of the expected GUI support things, but it had a unique and extremely desirable feature: using its dynamic link library (DLL) feature, you could create tools that configured themselves dynamically. The instant I learned this, I knew Windows would have a huge and successful future. I learned one other very important fact about Windows at that time: Its shell program was terrible.
Microsoft’s original shell, called MSDOS.EXE, was extremely stupid, and it was one of the main stumbling blocks to the initial success of Windows.
In my spare time, I immediately began to write a better shell program than the one Windows came with. I called it “Tripod.” Microsoft’s original shell, called MSDOS.EXE, was extremely stupid, and it was one of the main stumbling blocks to the initial success of Windows. Tripod attempted to solve the problem by being easier to use and configure. But it wasn’t until late in 1987, when I was interviewing a corporate client, that the key design strategy for Tripod popped into my head. As this IS manager explained to me his need to create and publish a wide range of shell solutions to his disparate user base, I realized the conundrum that there is no such thing as an ideal shell. Every user would need their own personal shell, configured to their own needs and skill levels. In an instant, I perceived the solution to the shell design problem: It would be a shell construction set—a tool where each user would be able to construct exactly the shell that they needed for their unique mix of applications and training. Instead of me telling the users what the ideal shell was, they could design their own, personalized ideal shell.
Once I had that vision, the particulars of the design fell into place with relative ease. There would be a palette of tools, and the user would be able to create “forms” and populate them with instances of the tools. The toolset would include standard controls like listboxes and push buttons but would also have special, shell-specific varieties, like listboxes that automatically showed the contents of a directory.
The first thing we did was throw out my prototype code and start over.
I began work on this new version of Tripod, and within a couple of months had a nearly complete, working prototype. I used C exclusively. One of the features that emerged during this period was the idea that the interface would be completely manipulable by drag and drop. The user could stitch two controls — I called them gizmos — together by right-clicking and dragging from one gizmo to another. A visual arrow connected them logically, going from an event at the first gizmo to a method of the second gizmo. Ultimately, Microsoft discarded the arrows, but the event/method model remains.
Because I was in the business of inventing programs and selling them to publishers, I began to show Tripod around the industry. Many companies in Silicon Valley saw it, but few expressed serious interest. However, in March of 1988, I showed this prototype to Bill Gates, and he immediately saw its potential. He declared that it was “cool” and that it would have a significant impact across his entire product line. Bill said he wanted to buy it, and over the next few months, we hammered out a deal. Because the name Tripod had had so much exposure, we promptly changed it to “Ruby.” Meanwhile, I put together a team of skilled programmers to build a release-quality program.
The team consisted of Mark Merker, Gary Kratkin, Mike Geary, and Frank Raab. The first thing we did was throw out my prototype code and start over. It had grown to over 25,000 lines of C code, and although it contained many valuable ideas, the code itself reflected its role as a test bed for different ideas. The whole team worked hard for the next 18 months to eventually produce Ruby. The product was vetted by Microsoft’s quality assurance team, and we shipped the golden master to Redmond in early 1990.
The Ruby product embodied many significant advances in software design, but two of them stand out as exceptionally successful. As I mentioned, the dynamic linking capability of Windows had always intrigued me, but having the tools and knowing what to do with them were two different things. With Ruby, I finally found two practical uses for dynamic linking, and the original program contained both. First, the language was both installable and could be extended dynamically. Second, the palette of gizmos could be added to dynamically.
Because Microsoft owned exclusive rights to Ruby, they could do with it as they pleased.
Ruby came with a small language, one suited only for executing the dozen or so simple commands that a shell program needs. However, this language was implemented as a chain of DLLs, any number of which could be installed at runtime. The internal parser would identify a verb and then pass it along the chain of DLLs until one of them acknowledged that it knew how to process the verb. If all of the DLLs passed, it meant that there was a syntax error. From our earliest discussions, both Microsoft and I had entertained the idea of growing the language, possibly even replacing it altogether with a “real” language. C was the candidate most frequently mentioned, but eventually, Microsoft took advantage of this dynamic interface to unplug our little shell language and replace it entirely with QuickBasic. This new marriage of language to visual front end was static and permanent, and although the original dynamic interface made the coupling possible, it was lost in the process.
From early on in the design process, I pushed the idea of making the gizmo palette dynamic. I envisioned a product where third-party vendors could write their own gizmo DLLs and users could add them to the product in the field without needing to recompile. We defined an interface whereby Ruby would interrogate nearby executable files with a query message. If the file responded appropriately, Ruby knew that it was a cooperating gizmo and proceeded to request its icon to display in the tool palette. This interface eventually became known as VBX. As far as I know, it was the first practical use of the dynamic linking facilities of Windows outside of the operating system itself. Its remarkable success vindicated the faith of both Microsoft for providing it and of myself for finding a practical application of it.
As far as I know, it was the first practical use of the dynamic linking facilities of Windows
Because Microsoft owned exclusive rights to Ruby, they could do with it as they pleased. The original intention was to ship it with Windows 3.0 as a new, more powerful and sophisticated shell, much like the one that would eventually accompany Windows 95. Instead, Microsoft decided to ship Windows 3.0 with a shell that looked almost exactly like the shell that came with OS|2, a product Microsoft owned at the time. The decision was made to delay shipping Ruby and convert it from a shell construction set for all users of Windows to a visual programming language for professional programmers by adding QuickBasic. At first, I was very frustrated by Microsoft’s decision and argued against it. However, I was impressed by the power of the eventual product and soon became an enthusiastic Visual Basic supporter.
During all the time I was working on Ruby, I was under a tight nondisclosure agreement with Microsoft and could tell no one about what I was working on. For a period of almost four years, I kept silent even though I knew that Ruby would change the programming landscape. Shortly after VB’s release, my friend Mitchell Waite telephoned me to ask whether or not I was the Cooper mentioned in VB’s About Box. I confessed that it was me, and he invited me to lunch so that he could hear the full story firsthand. We met in San Francisco, and I related to him the same story I have just told you. When I was finished, he looked at me in amazement and pronounced, “That makes you the father of Visual Basic!”
I have two sons, who were 9 and 10 years old when I first wrote this essay, and although I was instrumental in their creation and remain a big part of their lives, they are independent-minded people in their own right. As I watch them grow in their own way and make their own decisions about their lives, I know what it really means to be a father, and Mitchell’s phrase strikes me as more appropriate every day. I created VB in the same way I created little Scott and Marty. I stand by as the proud father of VB as it grows and matures and creates a culture all its own.
In May of 1994, at the Windows World conference in Atlanta, Georgia, Bill Gates awarded me one of only seven Windows Pioneer Awards for my part in making Windows a success through the creation of Visual Basic. You can watch me — and my hair — accept the award and answer Bill’s questions here.