Programming Windows: Visual Basic Takes Over the World (Premium)

To understand why Visual Basic was such a sensation, consider again how horrible it was to create even the simplest application using the C programming language and the Windows API: The modern example of a basic Charles Petzold hello, world-type application that I provided in Programming Windows: Hello, Windows (Premium) is almost 100 lines of code, is hard to read and understand, and is not particularly scalable. But a Visual Basic version of this same application, as I demonstrated in Programming Windows: Hello, Visual Basic (Premium), can be made without any code whatsoever. A version that does use code can be as short as two lines of user-created code.

That’s amazing. But both versions of the Hello, Visual Basic application only hint at the inherent superiority of this environment, especially when building application user interfaces. Designed to be as compatible as possible with Microsoft’s earlier Basic language efforts, in particular QBasic/QuickBasic, the Visual Basic language itself was simple and easy to read (and write). It utilized some basic (ahem) Object-Oriented Programming (OOP) techniques that made particular sense for those creating a GUI-based Windows application. And unlike with Windows API development, handling the events that drove the Windows experience wasn’t just simple in Visual Basic, it was obvious and even fun.

At a high level, the process was similar. As with a C-based Windows API application, Visual Basic applications had an entry point and usually had a single or primary window. They also processed messages related to events, which could be user-generated (a mouse click, perhaps) or system-generated. In both cases, it was up to the developer to determine which events they would respond to.

But where Windows API-based applications required a complex message processing loop, Visual Basic handled event processing in a more modular and manageable way, isolating the developer from the intricacies of the underlying system. Visual Basic abstracted the difficulties of the Windows API into a system that was easier to learn, easier to use, and easier to master.

A simple example.

When you started Visual Basic, you were presented with a basic application consisting of a single resizable window, which VB idiosyncratically called a form because of its roots in Alan Cooper’s Ruby. This act alone represented many dozens of lines of code that never needed to be written. But the real strength of Visual Basic came via the toolbox of controls—labels, text boxes, buttons, and many others—that one could drag and drop and arrange on the form. And with the ease with which one could handle the events that would happen to that form and its controls.

Consider a basic button control. As even a non-programmer would know, the most obvious event that happens to a button is a mouse click. And so Visual Basic would generate the code for a click event handler if a command button, as VB called it, was placed on a form and double-clicked.

As noted by the SUB keyword, Command1_Click() was a Basic subroutine. It ran when the button—named Command1—was clicked. If you added the Basic command END to the subroutine, the application would close (“end”) when the button was clicked.

The code window that appeared when you double-clicked an object had two drop-down list boxes, Object and Proc, that let you switch between the objects in the program—the form and whatever controls you added—and the various event procedures (subroutines) that were associated with each.

Practically speaking, this meant, among other things, that you could easily see which other events the selected control (or form) could handle by selecting the Proc drop-down. And you could then select one of those other events to generate a subroutine that could handle another event.

You could also select the form or another control in the Object drop-down, examine what events that object can handle, and then create event-handling subroutines (event procedures) accordingly.

This system was vaguely but not truly object-oriented, a term I’ll be discussing more in the future. Instead, Visual Basic was more correctly called “object-based,” meaning that it in addition to supporting events, it featured objects with properties (attributes) that could be accessed and also set (changed). But the objects in Visual Basic lacked some of the more sophisticated and complex capabilities of truly object-oriented objects. Like so much in VB, they got the job done in a way that was easy to understand and work with.

But Visual Basic had a secret weapon, too: It was extensible, both in the traditional sense—via DLLs, written in C or any other language that could add missing Windows API features—and via add-in custom controls. That latter capability came to the product courtesy of Ruby creator Alan Cooper who, as you’ll recall, allowed developers to extend that earlier product with what he called “gizmos.”

In the first three versions of Visual Basic, these add-in controls were called Visual Basic Extensions (VBXs), and they were implemented as a special kind of DLL with a unique *.vbx file extension. A bustling market for these controls quickly appeared, providing developers with an ever-growing library of controls from which to choose. Microsoft bought and packaged many third-party VBXs and sold them in a more expensive Professional version of Visual Basic too.

(Visual Basic 4 introduced a new kind of 32-bit custom control format called the OLE Custom Control, or OCX. OLE controls were not compatible with VBXs or vice versa, just one of many speedbumps in the transition to Windows 95, Windows NT, and 32-bit computing.)

“With Visual Basic, Windows programming becomes almost easy,” Byte Magazine noted in a January 1991 issue in which the product was voted one of the very best of the year. “Visual Basic has brought Windows programming to thousands of BASIC users. It offers programmers all the necessary tools for designing a Windows application.”

Given the ease of use and the praise, Visual Basic may seem nearly perfect. But the environment suffered from two major flaws as well. Applications written in Visual Basic often didn’t perform as quickly as native applications because of its interpreted nature; a Visual Basic runtime engine would interpret the p-code that VB generated. (This was eventually addressed in VB5.) And the language itself was both unsophisticated and inconsistent.

(Fun aside. In 1995 or so, I co-taught a Visual Basic class at Scottsdale Community College that ultimately evolved into sessions where we’d present code to the class, ask what they thought it should do, and then show them that their logical assumptions about code flow were usually confounded the weirdly unpredictable language.)

Whatever the reason, Visual Basic was often derided by “real” programmers for its flaws, and it was equated to the kiddie rides at an amusement park: Cute, but something you’ll grow out of. They complained that VB wasn’t a true OOP language and that, as such, it would always be unsophisticated and impractical for truly professional applications.

In my view, Visual Basic might have been too good in the sense that it attracted too many amateur developers, at least in the eyes of the professionals. It made a previously difficult activity, accessible only to professionals with expensive training, available to average people. It exploded the market for Windows applications, but some of them were unprofessionally designed and made.

Whatever your take on Visual Basic, history shows that Microsoft eventually sided with the naysayers and molded Visual Basic into something that was truly object-oriented and more professional, but also completely inaccessible to beginners. In doing this, Microsoft brought its original product, BASIC, into the 21st century. But the transition would also cost Visual Basic its soul.