Why Visual Basic 6 was frozen
It sounds like perfection. Microsoft had perhaps the largest number of developers in the world hooked on a language which in turn was hooked to Windows. Yet Microsoft took this asset, of incalculable value, and apparently tossed it aside. Back in 2002, it announced that the language was to be replaced by something new, different and incompatible. That caused rumblings that continue today. Developers expressed emotions ranging from frustration to anger. They felt betrayed. What follows is the explanation.
To think this through, we need to hold in our minds three things.
First, there is the Windows API. By this I mean the low-level programming interface to Windows, as explained in books like Charles Petzold’s Programming Windows. It is primarily a C interface. Every Windows programming tool compiles code that calls the Windows API.
Second, there is COM, which stands for the Component Object Model. So what is COM? Essentially, it is a mechanism for linking software components together. It is a binary standard, so it works with compiled code at runtime. COM is a family of technologies. One of them is ActiveX controls as found in both Internet Explorer and Visual Basic. There is also COM automation, used in Microsoft Office and elsewhere to control one application from another. A third COM standard is OLE (Object Linking and Embedding), used when you insert an Excel spreadsheet into a Word document.
Third, there is .NET. The .NET Framework is Microsoft’s replacement for COM. I’ve already written about the rationale behind .NET; it’s a bit out of date, but mostly still applies. COM was replaced because it was failing. It is a tightly-coupled binary standard, which makes it frail for Internet applications. It is highly complex, which was one of the reasons developers were moving from VB to Java. It also has versioning problems, causing software failures.
By contrast, .NET has a loosely-coupled architecture, idea for Internet and mobile applications. It is also designed for ease of development, and has many security and versioning features that could not easily be added to COM.
It is hard to understate the significance of Microsoft’s shift from COM to .NET. I think we should assume that the company would not have done so if there had been a good alternative. If industry politics had allowed, It could have moved towards Java rather than .NET, but the move away from COM was necessary in order for the Microsoft platform to remain viable.
Today, with the family of technologies called Indigo, the extent of this move is becoming even more apparent. Indigo replaces COM+, the COM-base transaction server which is key to distributed Enterprise applications on Windows. Indigo is also the new standard for XML Web Services, message queuing, transaction management and remote objects, and even inter-process communications. Indigo is built on the second version of the .NET Framework.
So what has this got to do with Visual Basic? I assume that sometime around the year 2000, when the plans for .NET were coming together, Microsoft looked at Visual Basic 6.0 and wondered what to do about it. VB6 was first released in September 1998, so it was due for an update. At the time, VB6 was a popular product, but also the source of considerable discontent. Developers bemoaned its lack of full object-orientation and its many anomalies. Another issue was the VB roadblock. Some things that you could do in C++ or in Borland’s Delphi could not be done in VB, or could be done only by monstrous hacks.
The truth is, VB was never intended to be a complete development language. It was intended to be a language for high-level composition of low-level components, a glue language if you like. For this reason, VB created a highly successful third-party industry in components, mostly ActiveX controls. These components were built mainly using C++, but used mainly from VB. Without ActiveX, VB would have been severely underpowered.
VB gets its component abilities from COM. In fact, VB is built using COM. It is not just a good COM client or server; it is a COM product. The object-orientation in VB is that of COM objects, which is why it doesn't do inheritance (COM is based on interfaces). Create a class module in VB6, and look at its Instancing property. Would you like PublicNotCreatable or GlobalSingleUse? These strange terms are COM features. In other words the technology on which VB was built was the technology .NET was replacing. There was no way VB could easily be adapted to become a .NET language.
Clearly Microsoft had to implement a new Visual Basic. However, it made what in my view was the only feasible decision. The company created a brand new product, maintaining compatibility with VB6 only where it could be done without damaging the new language. In one or two cases it maintained broken features in VB6 for the sake of compatibility (the strange array dimensioning comes to mind), but in general it made the new stuff clean. The new product solved many of the issues that afflicted VB6. It removes most anomalies, supports full object orientation, removes the dependency on a single IDE (VB .NET has a command-line compiler), and largely removes the roadblock, putting VB on a par with any other .NET language.
The compatibility problem
However there was a huge price to pay, and that was compatibility. Let’s think for a moment about what this means. Imagine you are a large organization which has used VB6 to build applications that play a key role in your business. There are hundreds of thousands of lines of VB6 code. The database architecture is based on ADO, the last COM-based database model. Now Microsoft says that VB6 is the end of the line. What do you do?
It's a bad scenario, and not uncommon. Microsoft’s official recommendation is either to port to .NET, or to freeze the existing application to maintenance only, and build new features in .NET using interop techniques to integrate the old with the new. Neither option is particularly attractive. Porting is a major effort, and your application developers have skills in VB6 and COM, not .NET. Interop is another idea, but often raises performance issues as well as tricky programming problems.
Microsoft does of course offer porting tools. Frankly, these have an impossible task. They can help a little, but there are many inherent problems. The main difficulty is not with the language, which converts reasonably well in most cases. The difficulty is with the class library, components, and GUI framework. The Visual Basic forms engine is nothing like the .NET Windows Forms library. ActiveX controls work to some extent in .NET, but they are sub-optimal and often cause problems. Worse still, advanced VB applications make considerable use of clever hacks and API calls which are bound to trip up any porting tool. Finally, COM has a totally different architecture to .NET. How is a porting tool ever going to re-architect your application successfully?
Mitigating factors
There can be mitigating factors. In general, applications which are mainly non-visual will either convert or interoperate more easily than visual applications. Applications which use best practice in terms of separating business logic from presentation code, and which use an object-oriented design, will be much easier to migrate or maintain than those which do not. However, even the best-written applications still have a problem.
COM is not altogether dead
Personally I like .NET. My general instinct when considering the future of a legacy VB application is to plan a new .NET or perhaps a Java application to replace it. However, that is not always realistic. There is another option, which is simply to continue with VB6. Some people are spooked by Microsoft withdrawing support. Here’s the latest official story. In summary, mainstream support ended in March 2005. Extended support, which is almost as good, runs until March 2008. However, the real support for VB6 is in the community and on the Web. By now, almost everything is known about the product. In addition, VB is (as we have seen) hugely extensible. You can call the Windows API; you can consume ActiveX controls; and you can create DLLs in other languages and call them from VB.
There is of course a theoretical risk that Longhorn or some other Windows release might break VB, locking developers to old versions of the operating system. However, this is vanishingly unlikely for the foreseeable future. Microsoft is not stupid. Why would it wreck adoption for a future Windows release by breaking VB apps?
Another factor is that Microsoft itself still uses VB. VBA remains the macro language of Microsoft Office. For that matter, Office is still primarily based on COM. This isn’t only because of legacy code. The .NET Framework does not have any equivalent to Object Linking and Embedding, which is used to great effect in Office. COM is not going away, not in Longhorn, nor in whatever comes after Longhorn.
Consider support for 16-bit applications as a parallel example. 16-bit applications still run in Windows XP, even DOS applications. However, they don’t run in 64-bit Windows. It was impractical to support three levels of Windows (16-bit, 32-bit, 64-bit) simultaneously. I’d expect that VB6 applications will still run for as long as 32-bit Windows is supported. I’d also expect that 32-bit Windows will have a much longer life than 16-bit Windows, since there are more applications out there, and the advantages of 64-bit over 32-bit are small for most users. Your VB6 applications will run for a long time yet.
I'm not suggesting that sticking with VB6 is an ideal solution. It is already dated in some areas, and will get increasingly so. For example, it is hard to support Windows XP Themes in a VB6 application. As Microsoft moves on with Avalon, Indigo, and other new Windows features, it will be difficult for VB6 developers to keep up. However, I doubt this is the main concern of organizations contemplating their VB6 applications. It is more likely that they just want their applications to work correctly.
What else could Microsoft have done?
This to me is the key question, neglected by many of those who feel let down by the abandonment of VB6. Clearly Microsoft could have stuck with COM and not done .NET. I don’t personally think that was a viable option; if Microsoft had done that, the migration away from Windows to Java and elsewhere would by now be huge. It could also have created a compatible VB7 as a separate stream of non-.NET development. This is actually what happened to FoxPro. The killer disadvantage is that this would have offered no migration path for VB developers who actually did want to use .NET. If Microsoft had done that, nobody would have taken its .NET strategy seriously. Or it could have done both VB7 and VB.NET. Confusion would reign. It might have worked as an appeasement strategy, but it would not make any difference to the underlying awful truth: the COM-based VB does not fit in the new .NET world.
I think Microsoft made the right decision in freezing VB6. The right decision in this context does not mean painless. Microsoft was in a bad place, and so was VB; it was always going to end it tears.
Postscript on Borland's Delphi
It is interesting to compare what Borland has done with Delphi to the way in which Microsoft has handled VB. Unlike VB, Delphi was never a COM-based tool. It supported COM, but its primary dependency is the Windows API. Again unlike VB, Delphi has been fully object-oriented from its first version. Therefore, Borland had some options not available to Microsoft. It was feasible for Borland to create Delphi for .NET with reasonable compatibility.
However, looking at what has happened to Delphi you can see that this approach also has its problems. Like VB6, Delphi has its own GUI class library which is different from .NET Windows Forms. Borland addressed this with a kitchen sink approach. The company provided Windows Forms support in Delphi, but also ported the Delphi GUI library to .NET, as an alternative to Windows Forms (VCL.NET). Which way should Delphi developers jump? You can choose your incompatibility. Choose VCL.NET, and live on the margins of .NET with a niche GUI library instead of the standard item. Choose Windows Forms, and greatly increase the porting effort for Win32 Delphi applications. Neither is ideal.
Of course Borland has also continued to update the native code version of Delphi. This is still where Delphi is most compelling. It’s also apparent that while Microsoft is moving away from COM, it is not really moving away from the Windows API, which is still being extended in Longhorn. So native code Delphi still makes sense as a product, as does Microsoft’s native code compiler, Visual C++.
It is true then that Delphi developers have an easier ride to the future than those on VB6. That does not prove that Borland loves its developers more; rather, it says something about the technical differences between the products. Visual Basic is a special case.
Copyright Tim Anderson 2nd July 2005. All rights reserved.