Why VB6 still matters

Visual Basic helped revolutionise the way we think about software. In fact, only a few years ago Visual Basic 6 (VB6) was the most popular development language, boasting three million developers. Today, there are still millions of developers using VB6, and there are still countless thousands of applications written in VB6 still in productive use.

The problem many of these developers and their customers now face is VB6 is no longer supported or being enhanced by Microsoft. Directly or indirectly, this means both the developers and their customers face increased costs.

Converting an application to VB.NET is often a huge process. The conversion wizard supplied by Microsoft produces hundreds or thousands of TODOs that need to be individually inspected and in many cases, needs to be reworked. Years of bug fixing and bringing a product to a high level of stability and quality can be instantly lost.

A common response to this dilemma is “so what, leave the code in VB6?”, however this fails to address the need for a customer’s code assets to grow with the company, and adapt to modern business needs. Also, If the code base stays in VB6, it still needs to be supported and developed.

A typical example could be a company payroll application. five years ago when the application was commissioned not only were the rules different but the technological environment was different too. Over time that application will need some minor tweaks, and may have new requirements such as interacting with Web services. Dated tools don’t facilitate that. Updated tools do.

The Web services example can be easily integrated with VB6. Office 2003 VBA actually has a great add-in for creating strongly typed Web services. This is just but one example of the technologies that can be brought to VB6. Indigo is yet another that has built-in COM support. GDI+ also is unmanaged. Side-by-side COM is also available for VB6 hence helping to address the common problems associated with dll hell.

So for VB6, Microsoft already has in place technologies that are ready to be integrated that help bring those applications forward. The aforementioned technologies combined with tools such as the VB Code Advisor could easily be combined and made available to VB6 customers.

The ultimate solution for the future of VB6 though would have to be integration with VB.NET. For example, a developer should be able to add a VB.NET class to your existing code and add new functionality using .NET. This is what the much publicised VB6 petition is asking for. This is exactly what Microsoft demanded for its own C++ code assets.

When it came to its own code Microsoft did not covert all its source code over to .NET. Instead it expended a lot of effort into allowing Microsoft to keep its existing code base and drop into managed code as it saw appropriate when writing new code.

For VB6 to be brought into the Visual Studio IDE to allow the same benefits as Microsoft afforded itself for C++ would take some time, probably 18 months to two years. If Microsoft started now, that would be ready the Visual Studio IDE, code-named Orcas or soon there after, and help bring VB6 applications to Longhorn and take advantage of the new platform.

It was and is reasonable for Microsoft to want to protect its own code assets, and bring them forward rather than re-write them all. Likewise it’s reasonable for its customers to expect to be treated the same. VB6 code needs to be brought forward, not abandoned by Microsoft.

Hundreds of Microsoft MVPs have already added their voice on this, thousands of customers have too. If you feel the same, let Microsoft know.

Bill McCarthy is a Microsoft MVP and chief executive officer at Total Environment