The two roads forward, VB/Windows and VB/DOS (1991–1992)

Once VB/Windows shipped in May 1991, Microsoft's BASIC organisation had a problem most companies would love to have: two viable, customer-facing branches of the same product, neither of which could be cheaply merged into the other.

The two branches

The split was structural, not strategic. The two branches descended from different code, different teams, and different platforms.

• VB/Windows was Cooper's form designer plus Embedded Basic plus a Windows-only IDE. It depended on the Windows USER API for window management, on the Windows message pump for input and event delivery, and on GDI for everything that drew to the screen. None of which existed on DOS. Porting it was not a port; it was a rewrite of the half of the product that mattered, against a target platform that had no equivalent of the services the original was built on.
• The DOS BASIC line (QuickBASIC 4.5 and BASIC PDS 7.1) was a fully realised compiler family with its own customers, its own libraries (ISAM database, financial functions, presentation graphics), and its own muscle memory in the form of millions of lines of QB source code. It was not going away.

Microsoft could not credibly tell the QuickBASIC and PDS customer base, "everything you've shipped is now a dead end, please rewrite it for Windows." Those customers were the BASIC dynasty, Microsoft's longest-running paid-customer relationship, fifteen years of compounded loyalty traceable straight back to the 1975 Altair interpreter that founded the company. By 1981 Microsoft BASIC was running on essentially every commercially significant microcomputer outside pure Apple hardware; the QB and PDS lines descended directly from that proliferation, and their customers were paying professional developers shipping commercial software in 1991. They were also, in 1991, mostly still on DOS. The Windows 3.0 wave was real but not yet universal, and they had been the original Microsoft revenue line for a decade and a half before Windows existed at all.

Microsoft's answer was to ship both.

Visual Basic 1.0 for MS-DOS, September 1992

Visual Basic 1.0 for MS-DOS went out in September 1992, about seventeen months after VB/Windows, as the explicit successor to QuickBASIC and BASIC PDS. The lineage is unambiguous: QuickBASIC 4.5 fed into BASIC PDS 7.1 fed into VB 1.0 for MS-DOS. It was not derived from VB/Windows. The compiler engine, the runtime libraries, the ISAM database, and the presentation-graphics and financial-function libraries all descended directly from the PDS 7.1 codebase that Microsoft had shipped in October 1990. What was new was the form designer grafted on top.

The seventeen-month gap between VB/Windows 1.0 in May 1991 and VB/DOS in September 1992 is almost exactly the time it would take to extend a finished BASIC PDS codebase with a text-mode form designer, which is what the deliverable suggests actually happened. The Microsoft team that did the work is not yet surfaced in the research for this section by name; Greg Whitten was Microsoft's BASIC architect through the QuickBASIC era and is the obvious starting point for direct outreach, but the VB/DOS-specific roster is a citation gap flagged in the source audit, not a settled fact.

Two editions shipped on 3½" floppies:

• Standard, three disks. Form designer, compiler, debugger, the basics.
• Professional, six disks. Added ISAM database, presentation graphics, financial functions, the rest of the BASIC PDS feature set carried forward.

The Standard and Professional split would later become the pricing pattern VB/Windows adopted from VB3 onward.

The text-mode form designer

The form designer is the part of VB/DOS worth lingering on. It is the conceptual transplant from VB/Windows (the idea of dragging controls onto a form and double-clicking to write the event handler) implemented on a target platform that had no graphics primitives, no windowing system, and no mouse beyond an optional DOS driver. The result was something nobody else had shipped: a usable visual form-design IDE running in 80 by 25 text mode.

The IDE faked a graphical environment with code page 437's box-drawing glyphs, the U+2500 to U+259F characters every DOS programmer of the era could recognise on sight. Forms were assembled out of coloured cells, simulated buttons, and panels drawn with single- and double-line box characters. Controls were dragged with arrow keys or, optionally, a DOS mouse driver if one was loaded. The compiled output was a standalone DOS .exe that ran in text mode and looked broadly like the IDE that produced it. Visually the editor was QuickBASIC's IDE (the blue background, the F-key menus, the side-by-side editor and immediate window) with form-design panes added.

The editorial point worth landing is that VB/DOS quietly invented a usable text-mode form-design idiom at exactly the moment the rest of the industry was abandoning the text-mode UI question entirely. Borland's Turbo Vision framework, the Norton Commander school of TUI applications, and the broader text-mode-application aesthetic of the early-nineties DOS world all converged on a similar visual vocabulary: coloured boxes, drop-down menus, dialog-style modal windows drawn in extended ASCII. VB/DOS was not the only product working in that vocabulary, but it was the only one that shipped a form designer on top of it. The contribution does not get retrospective credit because the platform underneath it was already on the way out, but it was a real piece of design work and it deserves to be named as such.

The form file format itself (what VB/DOS wrote to disk when you saved a form, and whether any compatibility tools survived to read it later) is a citation gap. WinWorld and Internet Archive both preserve install media for the Standard and Professional editions, so the answer is recoverable; it has not been pulled into this section yet and is flagged in the source audit.

Same name, different code

Programs were not source-compatible between VB/DOS and VB/Windows. Different runtime, different control set, different form file format, different language dialect on the margins. The two products shared a name and a marketing campaign and almost nothing else technically.

This is the defining oddity of the early VB era. It is also the reason most retrospectives written by people who weren't there get the order wrong. The instinct, decades later, is to assume the DOS version came first and the Windows version was the upgrade. That's the order that would have made sense if VB had been a single product evolving toward graphical UI. It wasn't. VB/Windows came first (May 1991). VB/DOS came second (September 1992). The DOS version was a sibling, not the original.

The DOS branch ends here

VB/DOS was the last product on the DOS BASIC branch. Microsoft never shipped VB 2.0 for DOS. VB/Windows 2.0 came out in November 1992, less than two months after VB/DOS shipped, and got all the future investment. For the existing PDS and QB customer base, VB/DOS was the upgrade path; for everyone else, the writing on the wall was clear.

The DOS branch dying that quickly should not be read as VB/DOS failing. It shipped, it sold, it satisfied the customers it was aimed at. It died because the platform underneath it was dying. The Windows 3.0 wave became the Windows 3.1 wave became the Windows 95 wave, and by 1995 the question of what to do about DOS BASIC programmers was answered by the fact that there were almost none of them left who hadn't migrated.

Where Chapter 2 picks up

That choice (same name, different ancestors, different code, ship both) is the seed of a lot of confusion that persists three decades later. Chapter 2 picks up there:

• VB 2.0 (November 1992) and 3.0 (Summer 1993). Instantiable forms, the VBX custom-control ecosystem that made every commercial VB project ship with three vendors' grids, and the Jet Database Engine in VB3 that turned VB into a database tool by accident.
• The team Microsoft kept and the team it didn't. Cooper had already gone independent before VB1 shipped, taking the Tripod and Ruby pedigree with him into the consultancy work that produced About Face and the discipline of interaction design. Most of the original Ruby crew followed him out of Microsoft over the next few years. The product they built kept running, on a different team, for the next decade.

Chapter 1 closes here. The lineage is collected: Dartmouth to Altair to QuickBASIC to PDS to VB/DOS on one branch, Cooper's Tripod to Ruby to Project Thunder to VB/Windows on the other. The people are named: Kemeny and Kurtz, Gates and Allen, Davidoff and Weiland and McDonald, Cooper and Ferguson and Geary and Fine, Whitten holding the BASIC architecture together across all of it. The propaganda machinery is mapped. And the two-roads-forward decision (same name, different code, ship both) is the seed of everything that follows. The question Chapter 2 answers is what Microsoft did with the road it actually invested in.

Sources

• Wikipedia, Visual Basic (classic)
• WinWorld, Microsoft Visual Basic 1.0 for DOS
• Cloudwisp, Exploring Visual Basic 1.0 for MS-DOS
• Internet Archive, Microsoft Visual Basic 1.0 Professional For MS DOS (1992)
• Internet Archive, Microsoft Visual Basic 1.0 Standard For MS DOS (1992)
• everyBASIC, MS Visual Basic for DOS
• qbasic.net, Compiler: QuickBASIC 4.5, QBX 7.1, Visual Basic for DOS