After the second version of Visual Basic there was no doubt that Visual Basic was here to stay. As with the development of any software product, it marched on. Visual Basic 2.0 was inexorably replaced and improved to create Visual Basic 3.0.
As a quick aside, I’ve been running these via VMWare. (mostly for convenience) However, because of my hardware, I’ve been having trouble getting some things to work. Primarily, accessing the FPU causes GP Faults due to how virtualization is handled. I was able to fix this, however, by using WINFLOAT.EXE, which is a self-extracting executable that contains a few useful FPU-related utilities, one of which, Hide87, I used to hide the FPU from Windows 3.1, allowing me to safely circumvent the error. I mention this mostly because I would imagine a lot of the usage of Windows 3.1 today may very well be for novelty purposes and research and access is probably done primarily through Virtualization software such as VMWare, and as such this discovery and toolset could be useful for others.
The Glue language
Spanning across 9 1.72 DMF Formatted Floppy Diskettes, Visual Basic 3.0 focused heavily on improving the data binding capabilities of the language as well as the System’s ability to interface with other applications. Added features include The Data Control as well as Data Bindable versions of the basic Controls, the Data Manager tool, OLE Automation Support, OLE Control update to OLE2, the Common Dialog Custom Control, Pop-up Menu support, Project Save-on-run support, the Setup Wizard, and Professional features such as Data Access support, Crystal Reports, the Outline Custom Control (more or less a simplified TreeView, enhancements to the CDK, and revised versions of the packaged Custom controls such as Masked Edit, 3D Panel, and Checkbox controls. Obviously trying to cover all these changes and their appropriate fiobles is beyond the scope of this post, but let’s cover some of the surface concerns.
One thing that also changes is that some of the features that were restricted to the Professional Edition of Visual Basic 2.0 are now available in the Standard Edition. By “some” I mean, well, one. In particular, the Common Dialog Custom Control I mentioned is indeed available in Visual Basic 2.0- but only the Professional Edition.
As far as I can tell, Visual Basic 3.0 feels like something of a “stopgap” release. Products often have these as they are about to switch gears with a major revision or change. Another good example of this is Windows ME, which was something of a stopGap release of what they had with the 9x consumer codebase before the major shift to the NT core with Windows XP. In the same fashion, Visual Basic 3 was followed by Visual Basic 4, which makes copious changes to to both the underlying technologies involved, as well as innumerable other components of the software product and result. This explains what appears to me to be a lack of features in Visual Basic 3.0 that really justify a Major version release.
The IDE looks very much the same as previous versions; or specifically, Visual Basic 2.0, which itself offered a number of changes that distinguish it rather readily from the Initial 1.0 Release. There have been of course minor tweaks and improvements across the board but the overwhelming feel is very much the same. Like VB2 before it I always felt that VB3 reinforced the idea of Visual Basic as a ‘glue language’ around other components. The default autoload.mak project loaded numerous extra controls, filling up the Toolbox. Programmers unfamiliar with Visual Basic often referred to the Toolbox as the “Toybox” because it was often filled with toys you may never use. Admittedly, I’m not sure if that’s the case, I’m just coming up with my own Supercilious terms and attributing them to people in the era. An interesting design change is that the display of sizing handles on controls was changed. It now uses anti-aliased circles instead of squares like Visual Basic 2.0.
There are a lot of people these days who like to build/tweak “retro gaming PCs” for DOS and Windows 3.1. I’d encourage those with an interest in old technologies to explore old programming technologies, including Visual Basic. People are very quick to dismiss such efforts as worthless or not worth the time- “When will you ever need it” but programming and computer science as an industry is still very young. If we insist on ignoring and forgetting where we came from we can easily lose track of where we are going and/or where we want to be. In any case I’d argue that things like older Visual Basic versions are both more interesting and more useful than the myriad of old Video Games people insist on putting on “retro” machines.