The most interesting reaction to my recent article covering the Microsoft–Sun settlement over Java wasn’t about Java itself, but it alerted me to the current newsgroup storm regarding the effort involved in rewriting applications from Microsoft’s Visual Basic 6.0 (VB6) to recompile on the soon-to-be-released (now in beta) Visual Basic .NET (VB.NET). Many CIOs have significant numbers of their companies’ developers trained in VB6 and thousands or millions of lines of Visual Basic code running significant systems in their businesses. In fact, I’ve heard Visual Basic referred to by more than one CIO as the “COBOL of the 90s.”
VB6 developers who are testing VB.NET have been complaining recently in newsgroups that the move from VB6 to VB.NET is neither simple nor automatic and will likely require significant code rewrites. Many developers are considering a move to C# on the .NET platform or even jumping to Linux or Solaris and rewriting their applications using Java. This isn’t the first time many of us old-timers have heard this discussion.
In the mid-80s, during the Microsoft/IBM OS/2 and IBM PS/2 heyday, developers complained about the effort of moving their applications from the Windows API to the OS/2 API. At the time, the vast majority of applications for the PC platform were developed in C, and the OS/2 APIs were similar enough to make the transition possible but implemented differently enough to make it costly. Recognizing the potential to alienate their Windows user base and developers, Microsoft allowed IBM to purchase the OS/2 code base and continued advancing the Windows platform into what is now Windows NT and Windows 2000 but what will become Windows.NET. IBM fought to convert developers and ultimately lost the war to Windows. Before I tell you the outcome of the VB6 versus VB.NET battle, let’s see what all the noise is about.
The times they are a-changin’
When Visual Basic 1.0 was released in 1991, it represented a major change in the way developers would write code for the Windows platform. Before Visual Basic, developers used text editors to write code, graphics editors to develop a program’s graphical elements, and stand-alone C compilers to generate executable code. Visual Basic combined a graphics design package, code editing tied to the visual elements, and a just-in-time compiler.
This revolutionary approach to an integrated environment changed the approach to software development and the expectations of developers. Now, anyone with a basic (excuse the pun) understanding of programming languages could develop robust, highly graphical computer programs for the Windows environment.
As the Windows platform matured and external forces caused Microsoft to rethink its platform architecture, Visual Basic became the flagship development product for the masses. Version 3 added database controls and simple, point-and-click ODBC database access. Version 4 added support for COM and OLE. In response to the movement toward client-server development, version 5 added client and server object development and communications capability. And when the Internet became a major development platform, Microsoft added DHTML, ASP, Transaction Services, and middle-tier object performance enhancements to version 6.
With very few exceptions, developers have been able to take their code from a previous version and recompile for the current one. Although this has helped to build the total number of active Visual Basic developers to a number somewhere north of 8 million, it’s also created an interesting problem for Microsoft: How do you take a language that was built on 16-bit, local area network-focused, procedural language underpinnings and make it work efficiently in a 32/64-bit, Internet-focused, language inheritance world?
Moving Visual Basic forward
If developers want to take advantage of all the new features provided in the .NET platform, they will have to rewrite significant portions of their applications. In order to update Visual Basic to a “current” language, it was necessary to remove some default behavior (Integers as 16-bit in VB6 are 32-bit by default in VB.NET), remove confusing or unused language primitives (there’s no logical reason to require SET commands for different types of assignments), move to a common type library with all other .NET languages, and add syntax to allow developers to take advantage of .NET features.
It’s also important to understand that the new features in VB.NET are those that VB developers have been begging for over the past few years. The top feature requests from VB developers—Intra and Inter Language Inheritance, free threading, advanced support for Web app development, support for remote debugging, and direct access to Windows APIs and services—have all been met with VB.NET.
Having said that, Microsoft provides two different paths for existing VB6 applications. First, VB6 developers have a mechanism for upgrading their existing applications. MS provides an upgrade tool (currently available in beta 1) that converts VB6 applications to VB.NET applications. The tool makes syntax changes where possible and flags areas that will require hand coding to work properly on the .NET platform.
Second, because Microsoft understands that not all of its customers will want to upgrade their existing VB6 applications to VB.NET, they provide a compatibility library that allows VB developers to seamlessly communicate between their existing VB6 applications and new VB.NET applications. And developers won’t be forced to move immediately to VB.NET. Microsoft will continue supporting VB6 applications through service packs and product support.
How should you deal with the VB6 versus VB.NET issue? First, let’s remember that even if VB.NET releases on time this fall, it will still be another six to 18 months before many companies will look at rewriting functioning applications to take advantage of the .NET framework. Second, you should recover the investment you’ve made in existing Visual Basic training and developers by looking for opportunities to use that knowledge and the .NET framework to develop new applications that take advantage of the unique features of .NET.
Finally, the Microsoft marketing machine will not allow the technical side of the house to release products that slaughter their development cash cow (VB6). I don’t see massive defections from VB6 to other platforms happening. It’s more likely that the extra training on the benefits of .NET versus the status quo will simply delay implementations of both .NET and VB.NET.
If you’d like to share your opinion, start a discussion below or send the editor an e-mail.