Much to Microsoft’s embarrassment, Visual Basic 6.0 is the product that refuses to go away. Earlier this year, a group of MVPs, (Most Valued Professionals) individuals that don’t work for Microsoft but offer strong voluntary support to the community, put together a Classic VB petition (http://classicvb.org/petition). The petition asked Microsoft to create a new version of VB to integrate with Visual Studio. What they want isn’t Visual Basic .NET, but a VB 7.0 that’s compatible with VB 6.0 and doesn’t require the .NET runtime.

Some of these people are diehards who don’t realise how broken the old-style VB is, but others are more pragmatic. They have a ton of VB 6.0 code and no idea how to migrate it. You can import a VB 6.0 project into Visual Studio .NET, but you are unlikely to be happy with the results. The problem isn’t with pure code and algorithms, but with COM, the Component Object Model that underpins both VB and VBA (Visual Basic for Applications, as used in Office). Ever since VB 4.0, the first 32-bit version of VB, Visual Basic has been a wrapper for COM. All its object-orientation is based on COM. Visual Basic controls are ActiveX controls, which are another form of COM.

Escape to .NET
This COM-dependence gives classic VB its great extensibility, along with characteristics that are perplexing to many developers who thought they had signed up for an easy to use programming tool. COM is based on interfaces rather than inheritance, which is why inheritance never appeared in classic VB despite many requests. It’s also responsible for the intricacies of features such as project compatibility vs binary compatibility, single-threaded vs apartment threaded, or PublicNotCreatable vs Multiuse – all options that appear when working with ActiveX projects.

Microsoft devised the .NET Framework in order to escape from COM, as there were ongoing problems with COM. It was too complex, too tightly coupled for web applications and too insecure and fragile, and prone to versioning problems. The new platform has automatic memory management through garbage collection, like Java. Security, versioning, and XML web services are all built-in. The .NET Framework is a cleaner and more productive programming platform, but fundamentally different from COM.

When you import a VB6 project into VB.NET, the IDE attempts to migrate the code, but it has little to no chance of success on any moderately complex project. Forms get scrambled because the GUI class library is so different and database code fails because ADO.NET bears no resemblance to any of VB’s myriad database APIs. More fundamentally, the architecture of the old VB application is unlikely to be right for .NET, and the wizard can’t be expected to redesign it for you – will Microsoft do classic VB 7.0?

There’s little chance that Microsoft will come up with a new version of classic VB. The main reason is platform strategy. COM is on the way out, so it makes no sense to encourage further development. The company has been desperate to persuade VB 6.0 programmers to migrate, with the latest inducement being all the free or nearly free goodies in the Express product series, due for launch in November. The second reason is that classic VB is broken. With all these devoted VB guys now bemoaning its loss, it’s easy to forget how much dissatisfaction there was with VB in the days before .NET. It was failing as Microsoft’s primary RAD tool and developers were fleeing to Java. The VB runtime is a black box, and if you need to do something that it doesn’t allow for, all the ease of use disappears and VB becomes obscure, complex and inconsistent.

Writers such as Bruce McKinney have documented this behaviour, and advanced VB developers should read his well-written book called ‘Hardcore Visual Basic’, which is freely available online (vb.mvps.org/hardcore). Sections such as the one on pointers, subtitled ‘Bring your hatchet’, demonstrate the effort involved in making VB behave like a grown-up language. This is because VB grew well beyond what it was originally designed for. It was only intended as a safe programming environment for gluing components together.

Broken behaviour
The quirks of Visual Basic pose a tricky problem for Microsoft. Visual Basic .NET was an opportunity to fix VB, but every fix made it harder to migrate old code. In most cases, Microsoft chose to break code rather than perpetuate bad features. Given that easy migration wasn’t going to happen anyway, that was the right decision. In a few cases, Microsoft maintained broken behaviour. This is why VB.NET array dimensioning is different from other .NET languages. They are always zero-based, but you declare them with the maximum upper bound, not the number of elements as in C#. If you want 12 elements in an array, you have to write:

Dim MonthlySales(11) as Decimal

This is unfortunate, but it was done in a futile attempt to ease porting. VB coders now have to live with this inconvenience. People often ask why Microsoft could not treat VB like C++, which can compile both native code and .NET code, or behave like Borland, which has a relatively smooth migration for Delphi from Win32 to .NET. These products are easier to migrate, because they lack VB’s tight dependence on COM. Even in the .NET era, Windows is still primarily coded in C and C++. Delphi wraps this lower-level Windows API, and has always had an object-oriented class library that isn’t far removed from the .NET Framework.

Back in the real world
Microsoft has good reasons to make VB 6.0 obsolete, but that doesn’t solve the real-world problem of what to do when you have a significant investment in VB 6.0 code. The main options are well-known: port the code to .NET or Java (which means throwing away much of it), stick with it, or find a hybrid solution like writing new code in .NET and calling into old VB code with COM interop or XML web services.

One of the frustrations of this decision is that moving to .NET is not all gain. In fact, for many things VB 6.0 is better. Most Windows boxes already have the VB runtime, whereas deploying the huge .NET runtime can be a major hassle, especially if you need to support Windows 98. VB 6.0 applications run faster and use less memory. If you need to interoperate with Microsoft Office or other COM applications, VB 6.0 is preferable since it’s based on COM. Despite Microsoft’s supposed strategy, COM is not going away in Windows or Office (see ‘Is COM really dead?’).

Classic VB developers are spooked because Microsoft is ending support for VB 6.0. This is a gradual process, some level of support is promised until March 2008 and possibly longer if you unravel the threads of how VB relates to VBA, and the fact that the runtime ships with Windows XP which will be supported for seven years after Windows Vista is released. If you can live with a dated GUI, none of this matters for the average small-scale VB home or business application. In cases where porting is difficult, keeping VB 6.0 going makes a lot of sense.