Provide a summary of the following web Content, written in the voice of the original author. If there is anything controversial please highlight the controversy. If there is something surprising, unique, or clever, please highlight that as well. Content:
Title: Something Pretty Right: The History and Legacy of Visual Basic
Site: retool.com
The Spring of 1988 In the spring of 1988, Alan Cooper sat in front of a computer in a large boardroom at the Microsoft headquarters in Redmond, Washington, patiently waiting for Bill Gates to arrive. At the time, Cooper's main business was writing desktop application software to sell to publishers. “I was one of the first companies to realize that you could retail software without needing to sell a computer,” he recalls. But for the past month, Cooper had been frantically coding in preparation for this Microsoft demo, adding last-minute features to Tripod, a shell construction set for the Windows operating system that he'd been working on as a side project. In late 1985 or early 1986, a friend had brought Cooper to Microsoft's annual technical conference in Silicon Valley. On stage was Steve Ballmer, presenting the first version of Windows. Cooper was impressed, not by the graphical multitasking system—something he'd already written himself—but by Microsoft's dynamic-link libraries, or DLLs. In Windows, much of the operating system's functionality was provided by DLLs, a new concept of shared libraries with code and data that could be used by more than one program at the same time. “Might as well have had a neon sign saying, ‘Market Opportunity.' And it just really intrigued me. So I started saying, ‘Okay, I'm going to build a shell.'” “There were some things that I couldn't do because I didn't have access to the deep guts of the operating system. And there were things that I wanted, which were interprocess communication, dynamic relocation, and [...] dynamic loading of modules that could run and go out without shutting down the operating system. So I went home and I put my little graphic frontend and multitasking dispatcher in the sock drawer and started building software in Windows,” Cooper explains. In Cooper's eyes, though, Windows had one major drawback. The shell—the graphical face of the operating system where you started programs and looked for files—was rudimentary, lacking overlapping windows and visual polish. Compared to Apple's Macintosh GUI released almost two years earlier, it was clearly an aspect of the project into which Microsoft just hadn't put much effort. “It was a program called MSDOS.exe and it was very clear that somebody had written it in a weekend,” Cooper observes. “[Microsoft] might as well have had a neon sign saying, ‘Market Opportunity.' And it just really intrigued me. So I started saying, ‘Okay, I'm going to build a shell.'” Windows 1.0's 16-bit shell ran on top of MS-DOS A program run from the command line called MS-DOS Executive (the equivalent of the modern day Explorer or Finder). Windows came with a few built-in programs—like a notepad, calculator, and clock—that could be launched into a non-overlapping application window by clicking the .exe file or an associate file, like a .doc. Ken Doe gives a detailed ten minute demo of the Windows 1.0 shell, 30 years after its release. A (not so) simple shell construction kit “I started writing little programs that could be shells for Windows,” Cooper remembers. “But that's actually a hard problem! You know, what would a shell be for Windows? It's an operating system that serves a lot of people.” Cooper's solution to this problem didn't click until late 1987, when a friend at Microsoft brought him along on a sales call with an IT manager at Bank of America. The manager explained that he needed Windows to be usable by all of the bank's employees: highly technical systems administrators, semi-technical analysts, and even users entirely unfamiliar with computers, like tellers. 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. Cooper began working on this new idea in earnest. His prototype had a palette of controls, such as buttons and listboxes, that users could drag and drop onto the screen, populating “forms.” Some of these controls were preconfigured for common shell functionality, like a listbox that automatically showed the contents of a directory. Michael Geary, one of the programmers that Cooper eventually hired to help with Tripod development, describes naming these elements: “They weren't called ‘controls' originally. Alan was going to call them ‘waldos', named after  remote manipulator arms . I couldn't make sense out of that name, so I called them ‘gizmos'. Microsoft must have thought this name was too frivolous, so they renamed them ‘controls'.” The “gizmos” would be a large part of what made Tripod groundbreaking: it wasn't so much what the resulting shells could do, but the interaction details which had never been well-implemented on a PC before. Cooper built drag-and-drop protocols and a sprite animation system from scratch. Tripod also used an event-driven model: when the user performed an action like clicking a button, it would trigger specific code to execute. To connect events fired by one gizmo to actions taken on another, users would drag out an arrow between the gizmos. Geary remembers this as the origin for the programming phrase “fire an event”: “I was looking for a name for one gizmo sending a message to another. I knew that SQL had ‘triggers,' and Windows had SendMessage but I didn't like those names. “I got frustrated one night and started firing rubber bands at my screen to help me think. It was a habit I had back then to shake up my thinking. Probably more practical on a tough glass CRT than on a modern flat screen! After firing a few rubber bands, I was still stuck. So I fired up a doobie to see if that would help. As I flicked my lighter and looked at the fire, it all came together. Fire a rubber band. Fire up a doobie. Fire an event!” “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?'” “Why can't we do stuff like this?” Once Cooper had a working prototype, he shopped it to publishers around the Valley. Everyone he spoke to told him the same thing: show it to Microsoft, we don't want any part of competing with them on this. Cooper had met Bill Gates years back in the early days of Microsoft, but they were hardly on speed dial. Cooper's friend at Microsoft managed to arrange an audience with Gabe Newell, then a mid-level executive who worked on Windows. (Newell went on to become co-founder and CEO of the video game company Valve.) When they finally met, Newell abruptly stopped Cooper five minutes into his demo: “Bill's got to see this.” He sent Cooper home and arranged for him to come back up to Redmond in a month to meet with Gates directly. Cooper spent the time furiously coding more features into Tripod. A month later (back to that spring of 1988), Cooper sat in that large Microsoft boardroom, but this time with Gates and an entourage of a dozen Microsoft employees. Cooper ran through the demo. “It blew his mind, he had never seen anything like it,” Cooper remembers of Gates's reaction, “at one point he turned to his retinue and asked ‘Why can't we do stuff like this?'” When one of the Microsoft employees pointed out some problems that the tool didn't address, Gates himself lept to Tripod's defense. “At that point I knew that something was going to happen,” Cooper says. Something did happen, although not exactly what he expected. There was no way he could know, sitting in that boardroom, that his project would eventually become Visual Basic, a visual programming environment that would reign for a decade and become the gateway to application programming for countless users. All he knew was that he had built something cool, something that no one had done before—not even the hotshots at Microsoft. From Tripod to Ruby Gates wanted Tripod. The parties hammered out a deal over the next few months. Cooper would finish the project and ensure it passed through Microsoft's rigorous formal QA process, at which point it would be bundled in the upcoming Windows 3.0. With contract in hand, Cooper wrote a detailed spec and hired a team of programmers—Frank Raab, Michael Geary, Gary Kratkin, and Mark Merker. Cooper decided to promptly throw away the 25,000 lines of messy prototype C code that comprised Tripod and start over from scratch, feeling like it was so irredeemably full of time-pressured hacks, it'd simply be easier to rewrite it with a cleaner design. Russell Werner, Microsoft's GM of the DOS and Windows business unit, was not pleased. “When Russ found out I had discarded [the code], he freaked out,” Cooper recalls. “He started shouting at me, saying that I would miss our deadlines, I would derail the entire project, and that I would delay the shipment of the whole Windows 3.0 product. Having presented him with a fait accompli, there was little he could do except predict failure.” The team dove into the rewrite—now codenamed “Ruby” to distinguish it from the prototype version. The Ruby Team in spring of 1989 From left to right:  Frank Raab, Mike Geary, Alan Cooper, Gary Kratkin and Mark Merker. A major change was architecting the gizmo palette to load in dynamically (using Windows' new DLL concept), with an API for third-party developers to create and distribute their own gizmos. Cooper describes the design decision: 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. 18 months after starting work In early 1990, Cooper's team turned over the golden master to Microsoft right on time. But Windows 3.0, it turns out, would ship eight months late anyway—and not include Ruby at all. From Ruby to Thunder Officially, Ruby wasn't included as the default Windows 3.0 shell because it wasn't keystroke-for keystroke, pixel-for-pixel, identical to the OS/2 shell. The more likely reason, though, was that Ruby was political collateral damage inside of Microsoft. Few remember that Microsoft was at this time simultaneously developing Windows and jointly developing the OS/2 operating system with IBM. Tensions between the teams—OS/2 was originally considered the more strategic product and Windows the underdog—boiled over with Ruby as a proxy fight. Cooper suspects that the root issue was professional jealousy; some of the engineers on the Windows team had been present at the 1988 demo when Gates had been ever so effusive about Tripod. “He was making all those guys hate me,” Cooper suggests, “because I showed them up, really badly.” Whatever the cause, Ruby was now orphaned inside of Microsoft less than a year after it was delivered. Frustrated, Cooper flew to Redmond, met with Bill Gates, and offered to buy the software back. “I said, ‘I'll release it myself, as a shell construction set for Windows'.” Gates refused. Cooper had no leverage, and Gates, according to Cooper, figured he could keep Ruby around and do something with it. And indeed he did. Gates loved BASIC—the programming language upon which Microsoft was founded—and believed that, with graphical user interfaces starting to define desktop computing, BASIC needed a visual component. Perhaps inspired by Apple's HyperCard, he came up with the idea of taking Ruby's visual programming frontend and replacing its small custom internal language with BASIC, effectively creating a visual programming language for developers. In a 1989 Byte article  celebrating the 25th birthday of BASIC , Gates hinted at what he'd directed the team to work on: After all, the best way to design a form is to draw the form, not write code to reproduce it. With a mouse and a palette of pre-dawn graphics images, you should be able to combine lines, boxes, and buttons interactively on a screen to design a form for a program. That kind of interactive design of objects should also let you attach to or combine your creations within a program. The Business Languages Group at Microsoft was tasked with making Gates's vision a reality. This was not received enthusiastically. The group was already stretched thin, charged with maintaining Microsoft's QuickBASIC IDE, the BASIC compiler, and developing a new language engine (dubbed Embedded Basic) for inclusion in a relational database product codenamed Omega (which would eventually become Microsoft Access). The Microsoft Business Language Group in 1990 (Image credit: Scott Ferguson) To pacify Gates, the unit staffed the project with a team of young, first-time leads, including Scott Ferguson, who was appointed Visual Basic's development lead and architect. Codenaming the project “Thunder,” the rookie team leaned hard on Michael Geary from Cooper's team to ease the transition. “While we were experts in the intricacies of Windows UI development b<truncated>