VB Classic Petition

Karl E. Peterson has organized a petition at ClassicVB.org in defence of unmanaged VB and VBA. I have signed this petition and on this page I want to explain why. Before I do, I have to point out to the VB.NET trolls that I am not a VB (classic) advocate. In the days before .NET I was a C++ developer. However, following the story of how Microsoft has treated VB (classic), how they have consistently ignored the concerns of their customers and refused to give assurances about existing code, it makes me wonder how they will treat other customers.

When .NET was first released I was not convinced that there was any need for VB.NET, and I am still of that opinion. All of .NET's features can be accessed through C# and this is the language that Microsoft have used to write their framework library. There is no need for another language and developing VB.NET took resources away from developing the framework. The framework library shows signs of poor design and cut corners and I think that if Microsoft hadn't diverted its resources towards VB.NET then the framework library would have been much better.

Microsoft chose to develop VB.NET purely for marketing reasons. They argued that VB developers would baulk at using a language that used curly braces and semicolons and would not move to .NET. Since the vast bulk of developers for Microsoft platforms are VB developers the success of .NET depended on shifting the majority of those developers to .NET. To do this they should have used a technological argument, but they didn't, instead they used a rather lame trick: they told VB developers that they could use their language in .NET.

Of course, VB.NET is not VB. Karl E. Peterson's site lists in great detail the incompatibilities between the languages. More importantly, the VB runtime is incompatible with .NET! VB (classic) is single threaded, it only generates STA objects, its error handling is not exception based (it uses COM error objects), and it has no inbuilt security. Moving from VB (classic) to .NET requires a huge shift in the way that a developer creates code, and if a huge shift is required surely curly braces and semicolons are no great inconvenience to that developer?

There is a huge VB (classic) code base out there and by killing off VB (classic) Microsoft has indicated that that code will die. Microsoft's rather pathetic solution is that developers should use the VB porting tool that is supplied with their enterprise edition of VS.NET. However, this tool cannot convert inherently single threaded, and often procedural, code into object orientated code. Instead, the tool ends up commenting out large portions of code that it simply cannot convert. In this situation the developer has not gained much, because the code then has to be redesigned to make it work under .NET. Whenever anyone asks me about this tool I tell them not to use it. Instead, I tell them that if they must re-use the code then the best way to do this is to re-engineer their VB (classic) code to have classes (it should have been written this way anyway) and compile it as a COM inproc server. Then .NET code can use COM interop to access the VB code. The advantage of this approach is that the VB (classic) code will continue to run in the environment where it was designed (and tested) to run: under the VB runtime, in the unmanaged world. Remember ported code is always ported code until you come to the inevitable point when you have to rewrite it. Ported code is a maintenance nightmare and in the long run costs more than a rewrite.

The huge VB code base is not static, it has to be maintained, and to do so requires a tool. Microsoft have announced that they will no longer provide free support for VB6 from January 2005. If you want support for VB6 after then (until 2008) you will have to pay for it. This is regardless of the fact that you have already paid for the developer licences that you use. Microsoft wants to kill off VB6 and they will do this by removing free support.

Microsoft is also on the verge of forcing another nail in VB's coffin. The major reason for providing MTS, and then COM+, was to give role based security, COM identity and authentication, threading and instance management to VB (classic). C++ could do all of those things (and transaction enlistment) without MTS or COM+, although I would admit that it would involve extra work. VB could not do any of those things and it would involve a complete rewrite of the language and runtime to provide them. COM+ was an elegant solution because those features were added by interception and hence they came for free. Microsoft's plan for Longhorn is to replace Web Services, .NET remoting and enterprise services with a managed framework codenamed Indigo. Enterprise services is .NET's name for COM+ component services, so on Longhorn COM+ will become legacy code. I suspect that Longhorn will have COM+, but also I suspect that it will not be developed any further. It's my speculation that COM+ will disappear in Blackcomb (the version of Windows after Longhorn). If that happens then no server code written in VB (classic) will be able to run. The release date of Blackcomb has not been made public, but I think that it will not be too far from the 2008 deadline when all VB paid support will cease.

I signed the petition at ClassicVB.org because I recognise that Microsoft has a huge responsibility to VB (classic) developers. I think that Microsoft's migration path to VB.NET is ill thought out and does no solve the issue. I think that their assertion that VB.NET is VB on the .NET platform is at best dishonest. I think the way that Microsoft have treated its concerned customers over this issue was disgraceful, they had every intention of developing VB.NET and were shocked when the VB (classic) community pointed out that the language was not VB. Microsoft's handling of this situation showed that they did not have their customers best interest in mind and this makes me worried for Microsoft's other customers. It also makes me worried for Microsoft too, because if they do not listen to their customers, and do not provide the products that their customers want, then Microsoft's success will be in danger.

If you are an MVP and agree with my comments, then I urge you to sign the petition too.