VB 6.0 Support Clarification

Two points from my previous blog that I was not totally clear on in my previous post so I wanted to highlight them.

First, during the Extended support period (April 1st on) if you have an MSDN subscriber or have a Premier or Alliance support contract the included free incidents do not expire and are valid through the extended support period.  I was a bit to vague and implied to some that these incidents would also expire.  This is not the case.

Second point of clarification for those of you with production code.  The VBRuntime ships in the box with Windows XP.  This means that the VBRuntime will continue in the Maintream support for 2 years for when ever Longhorn ships and 5 years after that point for Extended Support (7 Years total from the shipping of Longhorn which won't be tomorrow).  When we talk about the end of Mainstream support for Visual Basic we are talking about the development environment.  Since the runtime is part of Windows XP you have some time until this support stops.

So problems with your production applications will be supported for some time to come.  Problems with the development tool itself will continue for another 3 years.

Just so I don't start some other rumor, the VBRuntime ships with XP, this does not mean it won't work with Longhorn.  I have checked with the Development group and it will work with Longhorn.  See my comments in the VB 6.0 Support blog for more details.

I hope that clears things up a bit for more people.  Sorry for any confusion.

Comments (21)

  1. NO says:


  2. Richard Bethell says:

    I know you guys want people moving over to VB.Net. And I will concede that some of the excuses people throw out as to why they won’t are weak – there is no learning curve to move to VB.Net really. If you are fluent in VB6 and understand programming concepts such as objects and classes, you need a few days at most.

    But here’s where Microsoft needs to do better. Many businesses, mine included, have done huge internal line of business applications in VB6. Nobody knows or cares how our internal development house did it, although they gladly use the tool we’ve built.

    But what that means for us is, how do we justify a huge migration project with no apparent payoff, from the end user perspective? How do I go to my CEO and say, "We need to be left alone for six months to do a big migration project, and the result will be the same program we had before!"

    Do you not realize we’ll get laughed at for such a thing? The Upgrade Wizard HAS to get better. It is good enough for widgets and utilities, but a lot of us can’t consider this migration, even to the point of risking letting support run out on us, because it just isn’t good enough. Whidbey brings some improvement, but you guys really need to get on top of this one if you want us moving.

    THAT is why VB6 developers STILL outnumber vb.net developers – you just haven’t given us enough of a path forwards.

  3. Marcel says:

    I program since a long time with VB and some time ago with Access. What is now happen with VB we see before with MS Access for example. From Access 2.0 till today the things change very much and almost all the time you’ve to adapt much in your code.

    For now, Microsoft promise the best for .NET … but what is in 5-6 years? Perhaps then we move to something again better and must adapt again all the things?

    Perhaps is time that Microsoft realize that peoples cannot rewrite every 5-6 years their applications. Why not update the VB6 to a VB7 with new features?

  4. OSS says:

    My opinion is:

    1. For web development, consider other platforms/languages such as Java, PHP, …

    2. For desktop development, consider cross-platform tools such as QT, Java, …


  5. Derek Schwartz says:

    I was reluctant to take the plunge with VB.NET, but now after migrating quite a few applications (and becoming pretty comfortable doing it), I’m glad I made the move. Once you experience how much better everything is with .NET, you’ll wonder why you wasted so much time with COM and 3rd-party junk, when so much functionality is now simply "built-in". You can code a similar program much faster using .NET namespaces and have it be much more reliable with much more informative error handling. I’ve also noticed a strange side-effect: It’s possible to look at C# code and completely understand it, since all of the Framework objects use the same syntax, methods, and properties. I can typically port C# functions to VB.NET without even knowing how to program in C#, just because of the excellent structure. Trust me, it’s better all-around…

  6. Richard Bethell says:

    It isn’t a lack of facility in either Visual Fred.NET, C#, or even C++ that is the problem Derek, at least not with my shop. I have developers fluent in all that (as I am myself.) Nor is the problem that we aren’t sold on .NET assemblies, or not disdainful enough of COM. I’ve been quite expert in programming with the .NET Framework since it was called the NGWS.

    The problem, as I described above, is line-of-business applications – serious applications with tens of thousands of lines of code in many layers of COM. You try passing this thing through the upgrade, and despite the use of many MS-prescribed best practices, certain critical aspects of the application pass through un-upgraded. The printer object – one of the most important things you can do in any application that is more than a utility – gets nothing more than a "you’ll have to rewrite this" comment.

    What worries me, even though there is some support for programmatic-printing upgrading in Whidbey, is that it’s wizard-translated code – rather than creating a compatibility class in VB.Net with substantially the same behaviour, we’ll have to rely on a wizard that does fine in simple scenarios, but completely blows up a larger application.

    I just can’t sell a major upgrade project to my superiors – one that brings them no new functionality, but does nothing more than allow us to keep making support calls.

    I will not stand down – I continue to maintain we have been ill-served by Microsoft in this matter. It defies all reason that the most highly-used programming language ever invented by anyone – bar none – is being left by its developer to rot on the vine, and then die.

  7. Larry Gatlin says:

    I know what you mean about the upgrade wizard. I Tried to run a couple of my applications thru the wizard. After it was done I had so many fixes to do, I decided I would have to completely rewrite the app from scratch. I’ve been trying to learn the vb.net but is slowly progressing as I still need to work on my VB6 applications. I can’t migrate to vb.net my VB6 app’s because the Development does not run on Win 98. I can’t upgrade to Winxp, because it does not support the DOS software I have to use at work. A lot of catch 22. I work for a County Government and they won’t get me a better laptop to use. Budgets!!!

  8. Matthew Chidester says:

    As a developer, I have the freedom to choose MS or non-MS tools. To avoid the same problem of upward compatibility, I won’t use .NET platform at all, no matter C# or VB.NET. I’m using JAVA – JBuilder and Netbeans, with broad choice of application servers (from high-end to low-end). I don’t want to be locked up by any vendor, especially MS – they are not the first time playing this kind of trick!

    Of course, I know it’s too late to switch to another tool for desktop application development! My suggestion is simply to keep VB6 for the coming years just for maintenance purpose. The advantage is that you don’t need to pay MS any more!

  9. Danny Bowman says:

    I think Richard Bethell nails the VB6 issue. Microsoft’s abandonment is reprehensible. But we need to remember: This is not about any kind of respect for a substantial VB6 developer base it created, it’s about money. Period. Being left "to rot on the vine, and then die" means nothing because it doesn’t cost Microsoft a dime.

    The abandonment of VB6 and its dedicated legions of developers is a simple stratagem for profit. All the cries of outrage and injustice mean nothing. The Microsoft money machine is as soulless and uncaring as any other corporate conglomerate.

    We professional VB6 developers have a decision to make. This MCSD, for one, is now looking at open source options…options that are based on a network of people…not profiteering technocrats.

  10. ergun says:


  11. krishnan ts says:

    i want to know which all platforms suport vb

  12. Krishnan T S says:

    which all extensions are for vb forms in linux

  13. i need it for brainbench study and like the book so much and it is interesting.

Skip to main content