by John Browne, on Dec 9, 2015 6:00:00 AM
Recently a customer wrote us, saying "Hey, if Microsoft says VB6 is still supported and will be for years and years, why should I worry? Why bother to migrate my app off that classic platform?"
Great question.
Let's do the short answer-long answer thing. Short answer: you don't have to, but you probably should.
Long answer follows.
As we all know, nothing lasts forever and Microsoft from time to time kills off old technologies. Sometimes, not so old. VB6, is now old enough, were it a human, to be a senior in high school. While that's young in human years (unless you're a high school senior, in which event you might believe yourself to be virtually ancient), for a piece of software it's pretty geriatric.
Consider the timeline: Microsoft dropped mainstream support for VB6 in 2005 (meaning no more enhancements); extended support in 2008 (meaning no more updates). However, our customer pointed us to this fairly recent post by Microsoft talking about the "it just works" commitment for older technologies in current operating systems. Our customer's interpretation of this article was that he had until 2024 to get off VB6.
Given that 360 Assembly is still running mainstream apps on IBM mainframes somewhere, why should anyone really be in a hurry to ditch something as relatively young as VB6? Do you really need to make this move or can you actually wait until 2024?
It just works. Kinda sorta.
What Microsoft is saying, if you read the article, is that the core VB6 runtime still works inside Windows 10 (and previous versions, including Windows Server versions). So absolutely some VB6 applications will continue to work today and tomorrow.
What won't work is a lot of the stuff that those applications need, like the extended runtime (that includes a lof of OCXs) as well as 3rd party controls. When VB6 was current, a significant ecosystem sprung up to extend the tool with custom controls using the OCX format. These controls were fantastic, allowing developers to drop in unique or large pieces of functionality without having to write a lot of original code. Today people say "there's an app for that;" back in the 90s people could say "there's a custom control for that." Some of the companies that made those controls are still around (and their stuff has morphed into something more modern) but plenty are gone. Some of those controls came with VB6 but are no longer supported.
A 64-bit world
The original IBM PC was cool because it was a (mostly) 16-bit architecture (16-bit CPU with 8-bit data bus). That lasted quite a while before the 386 became common and with it 32-bitness. In the 90s when people were cranking out VB apps faster than the dude deep-frying candy bars at the state fair, a lot of those apps needed to run on the zillions of 16-bit PCs out in the world. Those apps could still play nice when Windows became 32-bits because backwards compability. But today 32-bits is old school and Windows has to do 32-bit stuff with an emulator (WOW). What's all this mean? Really old apps won't work on 64-bit Windows or even WOW if they rely on 16-bit OCXs. Those apps are still running on Windows XP or Server 2003 which present their own set of problems (out of vendor support).
The final word
So yes, you can run those VB6 apps into the ground, like my old 1945 Ford 9N tractor I used to have. But frankly when I traded it in on a new Kubota 4WD with hydrostatic transmission and front-end loader, I was so much happier and got a whole lot more work done.
