After years of learning how Windows works under the “hood”, as a WIN32 API programmer, I can look back at classic Visual Basic from a different perspective and see how it could have been designed better right from the start. As a long time BASIC programmer, I appreciated how easy it was to write Windows software with Visual Basic. Yet, right from the start I could sense something was missing.
BASIC programmers value real compilers
BASIC as a language is viewed by most programmers today with distaste. Often the “young generation” of today’s programmers make comments about GOTO, line numbers and it being an interpreter. How little they understand about BASIC ! Even back in the early 1980’s, Commodore 64 programmers, like myself, were using BASIC compilers (Abacus Basic) and learning machine language (6502). You want every tiny bit of performance you can grasp when writing software for a computer with a 1 MHz CPU (C64). When IBM compatible computers became the fashion, Microsoft QuickBasic and later PDS 7.1 (Professional Basic) were powerful compilers, even allowing programmers to embed modules written in other languages (ie. I used assembler to write some UI features). BASIC programmers back then, much like todays C (notice I say C, rather than C++) programmers, valued raw programming power and appreciated the importance of a fast, high performance compiler. Microsoft was not the only major software company creating powerful BASIC compilers back then. Borland International was a major development tool company and they purchased the rights to an excellent BASIC compiler and named it Turbo Basic (when Borland got out of the development tools business, they sold the rights back to its original developer, Bob Zale and he renamed it Powerbasic and PowerBasic compilers are still around today, albeit for Windows now).
So when classic Visual Basic came on the scene, it was lacking in a number of areas, but despite that, its powerful visual design front end compensated a great deal and it became one of the most popular programming languages of its time. Yet even back then, some BASIC programmers found it wanting, but not for the reasons you might think. Ease of use could only go so far. What Visual Basic lacked was raw power and likely many VB programmers didn’t fully understand why it was missing. Many yearned for a real compiler, thinking that this key lack was the primary cause for Visual Basic’s lack of raw power. That was only part of the problem, as I will discuss later in this article.
Why wasn’t classic Visual Basic a compiler right from the start ?
Classic Visual Basic was not originally a Microsoft product developed from scratch by them. I never knew this back then, but history has revealed much about Visual Basic we didn’t know back then. The short version of the story, is that it was not even originally designed to be BASIC nor was it designed to be a compiler. It was a Shell construction set program created by Alan Cooper and his team of developers. It was scooped up by Microsoft and eventually was reworked to become classic Visual Basic 1.0.
Note: You can read about the real story here on Alan Coopers website:
Alan Cooper, the Father of Visual Basic
So Visual Basic’s start differed from how a programming language, especially a compiler, is usually created. It was all about the drag and drop visual design environment, rather than building a high performance compiler. This plagued Visual Basic for years until Microsoft actually made it a real compiler and from what I have read (if true) is that they had to use a C compiler backend to accomplish this. Classic Visual Basic versions 5 and 6 could compile to real native code, rather than simply use a PCode compiler like previous versions.
Something else was missing and most did not realize it
But there was more missing from classic Visual Basic and sadly most didn’t realize it. Visual Basic was a major change in programming styles at the time and this greatly affected the performance of VB applications. While the drag and drop environment was a huge success (and necessary), something else changed how the software worked and drastically reduced performance and efficiency. Most early VB programmers found the shift from DOS to Windows to be extremely challenging. Visual Basic was a breath of fresh air for them, since it solved the biggest challenge they faced, which was user interface design. Writing code for Windows apps was not easy back then and learning the Windows API was just too much of challenge at first, when making the shift to Windows. Visual Basic’s easy drag and drop front end made programming fun again and made it possible for many DOS Basic programmers to make the shift to Windows. But in short order many Basic programmers found Visual Basic lacking, particularly when it came to missing features. How does one add new features not currently supported by the language ? The solution was both a pro and con for VB’ers. ActiveX controls !!! Yes, new features could be added via ActiveX controls. Later they were changed to OCX controls, but it was the same concept. But here is the problem. ActiveX controls were being written in C, not Visual Basic. Why ? Likely, because Visual Basic was not a true compiler at the start and also because of something which few appreciated at the time. Windows, “under the hood” was not object oriented and did not work the same way Visual Basic did. Yes, Visual Basic shielded the programmer so much from the Windows API, that it was often a challenge for VB programmers to start learning how to use API code in their VB apps. The problem is that Visual Basic was a UI framework built on top of the Windows API, but using an OOP (Object Oriented Programming) framework, rather than a procedural one.
As a long time WIN32 programmer, I see two problems with this. First, creating addon modules for Visual Basic required not only using C or C++, but to maintain the OOP framework design to match Visual Basic, modules would most likely be written in C++ using OOP as well. But wasn’t the WIN32 API procedurally based ? Yes, it was, but even fast performing C++ code (OOP) will never perform as fast as native WIN32 procedural code. This explains why it was more efficient to often call a Windows API directly in a VB app, rather than to use an ActiveX (or OCX) control to add a feature. A good example is the common Dialogs, such as Open File or Save File Dialogs. The size of the modules (OCX) to provide these features are huge compared to simply making the calls directly using the WIN32 API.
The benefits of using a procedurally based UI framework were lost
If classic Visual Basic was written from scratch as a true compiler right from the start, it might have been possible to write a procedurally based UI framework rather than an OOP based one and there would have been a significant difference in performance. Now some might say, “that is just a theory” or “conjecture” on my part to say that. Actually is it a fact based on real experience. Why can I say that ?
While I started out as a classic Visual Basic programmer (starting with version 1.0 and lastly version 5.0 Pro), I came to the conclusion that something was missing and I longed for a real compiler, but one that encouraged me to code procedurally, while giving me the raw performance that C programmers have long enjoyed. I found that with the Powerbasic compiler for Windows. The problem though, was that when I started with the Powerbasic compiler it was an early version (1.0 for 16 bit and 5.0 for 32 bit) and while it had all the raw power of C, it was missing a GUI framework (other than accessing the WIN32 directly) and had no drag and drop visual designer. So how was one to code with the likes of that ?
Well, simply put, it was nearly impossible. But rather than give up on the language, I chose the most difficult route and that was to learn the WIN32 API. But I quickly found out how challenging that was and learned that I was never going to be able to be a productive Windows app developer by using the WIN32 API alone. Maybe I was spoiled by Visual Basic or maybe I simply was just being realistic. Even Microsoft found coding using the WIN32 API directly too challenging and quickly shifted to MFC (Microsoft Foundation Classes) and ATL. So why couldn’t I start building my own UI framework ? Made sense, but there was something else to consider. First, the mainstream programming world chose OOP for building UI frameworks, but the WIN32 was not OOP based. Second, even if I could write my own UI framework, without a drag and drop visual designer, hand coding would make it a challenge. So what was a budding WIN32 (and BASIC) programmer to do ?
Using what I had learning from years of DOS BASIC programming
How little most programmers today understand about the “real” BASIC programmers of the 1980’s and 1990’s. Rather than a bunch of “beginners” who can’t handle a “real” programming language, they often were hard working, experienced and creative. For example, back in the “old days”, BASIC programmers like myself were learning low level programming, building high level libraries for a variety of tasks and even pushing the limits of user interface design. If one couldn’t do it in BASIC, they we often would resort to assembler. We often would build user interface frameworks of our own which, despite running on a text based display, would rival even what today’s GUI frameworks can do (ie. I built my own Listview like display long before Windows and the Listview control existed).
So when I started learning the Windows API, I made an important decision. Everything I learned would be put into a reusable UI library, rather than actually code a UI directly using the WIN32 API. Second, this UI framework would be procedurally based, rather than OOP based. Third, the UI framework would be designed so I could hand code an app simply using the framework, so it had to be easy to use. Fourth, the UI framework would not be a closed “black box”, but instead would be designed so I could easily integrate direct API code if I wished. This meant add “hooks” into key parts of the engine, so I could even override it if necessary.
So I began to build my first generation procedurally based UI framework. But I quickly realized that one key component was missing. At some point, I needed a real drag and drop designer. I was experienced at writing code generators, even back in the DOS days. Even BASIC programmers back then appreciated the value of automation, such as code generators. I made one key choice from the beginning though, which I think was vital. Everything I learned about drag and drop design, would be included in the UI framework. It would be a core part of it.
What experience, in building a procedural WIN32 UI framework, has taught me
So after 20 years of working on a procedural WIN32 UI framework, what has it taught me ? First, that procedural UI frameworks can produce very efficient , high performance applications. Second, procedural UI frameworks are significantly faster and smaller than their OOP based counterparts. Third, drag and drop design is vital for any UI framework today. So, can a procedurally based UI framework really be more efficient than an OOP based counterpart ? Let’s compare a procedural framework and compare it to classic Visual Basic’s framework when it comes to size, as well as feature set. Using my 5th generation UI framework for use with Powerbasic, which is simply standard Windows Dynamic Link Libraries (DLLs) and comparing it to the size and features in classic Visual Basic’s runtime library, one quickly sees a big difference.
First, Visual Basic 5.0 Pro runtimes for a typical application:
msvbvm50.dll – 1324 KB
comdlg32.ocx – 150 KB
comctl32.ocx – 595 KB
comct232.ocx – 161 KB
mscomct2.ocx – 633 KB
richtx32.ocx – 208 KB
For a total of 3071 KB in size. One can’t even use the most typical common controls in Visual Basic with having to use extra OCX controls.
My 5th generation UI framework for a typical application only requires on DLL which is about 700 KB in size and when using the extra DLLs for some special features it all totals only about 1000 Kb (or 1 megabyte). That is 1/3rd the size of the typical VB runtimes and no modules need to be registered with the operating system. But it does not end there. This framework also includes the following which is not in the Visual Basic core runtimes:
2D Sprite animation engine
3D OpenGL based scripting language
Drag and Drop engine for building Visual Designers
Custom controls, such as Property Listbox, Files Listbox, MCI control, Drag Handle control (for drag and drop engine), Masked Edit control, Turtle Graphics control, Hot Spot control, Splitterbar control and low level Canvas control with 22 image filters built in. The framework supports Theme drawing, ownerdraw and customdraw. It supports all the common dialogs, has a print engine, supports Threading and a Game Loop engine. The entire command set is the size of many programming languages with over 1000 commands in it. It even supports low level superclassing and subclassing of controls.
So how can a UI framework support so much more than classic Visual Basic, with a footprint of 1/3rd the size ? Because it is procedurally based like the WIN32 API is. Also by using a fast, powerful native code BASIC compiler, the results are impressive to say the least.
So what would have classic Visual Basic been like if it was written from the ground up as a real native code compiler ? Likely it would still be in use today and would not have been superceded by VB.NET.
