Visual Basic for DOS. (program development software) (Software Review) (Evaluation)
by Tom Campbell

It wasn't much of a stretch for DOS die-hards to look wistfully at Microsoft's Visual Basic, the most popular Windows programming environment on the market, and wish that some of the pixie dust would rub off on QuickBASIC. Five years old and counting, QuickBASIC is an excellent value, but lately it's really been showing its age. When Microsoft, with its huge investment in Windows, announced that QuickBASIC wouldn't be updated, my heart sank; this didn't bode well for me and millions of other QuickBASIC programmers.

What I didn't know was that QuickBASIC was to be replaced by Visual Basic for DOS, a worthy successor with advantages even its Windows counterpart lacks. If you're not familiar with Visual Basic for Windows, here's a brief rundown on how it works. This description will also apply to Visual Basic for DOS.

A Visual Basic program, like a Windows program, is inextricably tied to its user interface. The program is made up of windows (which Visual Basic calls forms); controls, such as buttons and scroll bars; and BASIC code. Typically, you design the user interface first by drawing" it in form view--adding forms (a.k.a. windows), check boxes, combo boxes, and so on. You've probably already figured out that this is an incredible time and money saver because you don't have to buy a windowing library and it allows you to create a prototype of the application at the very start. This eliminates a lot of communications problems if anyone else is involved in the design of your application (for example, the person paying you!).

And let's face it--it's a lot more fun than laboriously designing the user interface on graph paper and then figuring out endless function calls to the windowing system. (There's also the potential drawback that the windowing interface isn't to your liking, but that can happen with any code library. In Windows, that's not a concern because the whole point is that all applications share a common GUI. The DOS world is more individualistic--so consider yourself warned. I will say that Microsoft has created a text-windowing scheme that's snappy and well designed, with the added benefit that it's one that works almost the same under DOS as it does under Windows.)

Program code gets triggered by events in the user interface--a click of a button, the cursor passing over a control, the user's entering text into an edit field, and so on.

What makes it all happen so smoothly is the way code is attached to forms and controls. For each conceivable event, the user interface object has its own method, or subroutine, For example, one of the button methods is called Click, To run code when that button is clicked, double-click on it in form view and you're switched to code view (in DOS, they're two separate programs due to memory limitations, but the context switch is quite rapid).

If you've just added the first button to the form, you'll be popped into a program-editing window for a subroutine already named SUB Command1_Click(). Enter whatever code you want, and that's it. No muss, no fuss. There are no resource editors and WM_PAINT routines a la Windows and C, and it's substantially easier even than BASIC add-on windowing libraries.

Visual Basic for Windows lets you create your own control types, but you must do so in C--and programming Windows in C is not a pretty sight. You can graft them onto Visual Basic's palette as if they were born there, however, and Visual Basic won't know the difference. Amazingly, Visual Basic for DOS lets you create custom controls in BASIC--a boon for users who bought BASIC to get away from C in the first place. My favorite control with Visual Basic for DOS is the text editor, which is a complete editor--mouse and all--that you can roll into your compiled applications (royalty free!) and which will handle up to 32K of text.

The forms/controls/code paradigm is a good one. I'm a slow learner, but I caught on to it fast, and I prowled Compuserve's MSBASIC forum for weeks without finding anyone who had prob lems with it. The toughest nut to crack is realizing that you lack control over the user's actions: You must be ready for any button click at any time or for the window to be resized at the user's whim. What surprised me about writing programs this way was that they become much better organized and easier to understand, and the slight amount of extra code is more than made up for by the thousands of lines of code saved by the windowing and control code Visual Basic for DOS already has built into each application.

The worst aspect of Visual Basic for Windows was its incompatibility with the DOS version, but amazingly, the DOS version doesn't have that problem. Your old, nonwindowed code will compile exactly as it did before, so moving to Visual Basic for DOS is utterly painless. The documentation helps here, too; the world-class docs that came with Professional Basic 7.1 but not QuickBASIC are back, and they're better than ever. Ditto for the online help, which obviated my need for the manual. Code quality is the same as its DOS predecessors.

Visual Basic for DOS is a worthy and splendid successor to QuickBASIC. Don't hesitate to make the upgrade if you were concerned about documentation, speed, overall quality, or ease of learning.