In the last 3-5 years I have been renewing an insurance application and a commmercial integration toolkit based on Visual Basic 6.0.
According to Microsoft's "It just works policy" the IDE is no longer supported after april 8th 2008.
It still works to develop and deploy Visual Basic 6.0 applications.
When will it be impossible to support Visual Basic 6.0 applications, or will they live forever like Cobol applications do?
Update: Microsoft statement march 2010: The Visual Basic team is committed to “It Just Works” compatibility for Visual Basic 6.0 applications on Windows Vista, Windows Server 2008 including R2, and Windows 7.
Update may 2011:
Happy 20th Birthday Visual Basic!
I think Visual Basic 6.0 will continue to work for a long time. For a start, .NET has failed as a development platform for commercially mass distributed applications. nobody seems to use it in the way Visual Basic 6.0/C++ were/are used. The .NET runtimes are STILL not reliably there (from experience, we pulled a .NET application and recoded it in C++ for this one reason)
I agree about employability, though.
Loosing Visual Basic 6.0 was a major mistake by Microsoft: they were hypnotised by the whole OO thing. Most people want rapid development, not pedantic arguments about beautiful code.
VBA has replaced Visual Basic 6.0 within offices: who thinks of manipulating Office via the .NET route?
I think they'll be there forever. Simple reason: MS can't ship an OS that doesn't support them because no major corporation would buy that OS.
The runtimes are still the nightmare with .NET.
I support code on 20,000-30,000 desktops and analyse the registry of them. The amount of PCs without any .NET runtimes (let alone 2+) is staggering. There is no way one can mass-distribute auxillary code to them (the core application is C++) without employing an army of support staff to hand-hold on the reboots.
C++ is the only way to go for client-side applications.
What a disaster the whole OO mirage has been for MS and so us! What a cost inflator!
... and ASP.NET webforms/viewstate... I could type for DAYS (our programming contractors clearly did.)
With virtualization using VirtualPC/VMWare/VirtualBox etc, it in theory should be possible to support VB6 applications provided you have a host OS that can run VB6 correctly that you can virtualize that can run these applications.
I'm thinking of many companies that run software written for NT4 that lack driver support for new machines in virtual machines.
There is a ton of vertical market software developed in VB6 by manufacturers of various types of machinery. VB6 use of ActiveX controls, ActiveX DLLs, and the ability to consume most Win32 DLLs has lead to many manufacturers of various components to support VB6.
Using VB6 and the support libraries is at least an order of magnitude faster and more reliable than the older methods of assembly on custom chips, or using C. Note that even the C/C++ developers were helped as they can consume the new support libraries as well.
Many of these applications are filled with math functions that have been tested to work for the environment and the machinery they were designed for.
So when Microsoft made VB.NET incompatible with VB6 this was a BIG deal for many of us. Unlike the transition from VB3 to VB4-6, we have to touch our code in many place in order to get it working with .NET. So many in fact that it devolves to the same thing as rewriting your software in a new language.
For these reasons VB6 will live on for a while longer as all these machines are out there. Still needing new updates and fixes.
VB6 probably will be around forever in insurance / bank type organizations. Hardware moving out of their realm is not an issue. They will simply get some form of emulator. I've seen an application for a very old mainframe working inside an emulator which was inside of another emulator.
It usually just doesnt make business sense for the non technicals to consider a rewrite and retest for something that already works. -
Welcome to the world of painful hell... get out now :-) -