News

VB6 Support About to Disappear

As planned, Redmond is ending Visual Basic 6.0 support this month, prompting enterprises to migrate to .NET.

The end is near! ... That is, if you're a Visual Basic (VB) 6.0 developer.

On April 8, Microsoft will cease its support of the VB6 IDE. This shouldn't be news, of course. Microsoft has been warning its customers about this for ages. And VB6, released in 1999, has been on extended support since 2005. The writing, it's safe to say, has been on the proverbial wall.

And yet, VB6 is still in remarkably widespread use. In a recent survey of North American and European IT decision makers, analysts at Forrester Research Inc. found that although VB6 usage is declining slightly, it's now the fourth-most-common language used by their developers (behind Java, Visual Basic.NET and C#). Microsoft is expected to offer custom support plans through 2012, but they won't be cheap.

Now that Visual Studio 2008 is available, what are all those VB6ers to do?

"What to do about VB6 is one of my No. 1 inquiry subjects from clients," says Gartner Inc. analyst Mark Driver. "People are in a panic around VB6. I'd say that 85 percent are still going to .NET, but they've put it off for so long-ignored it, had larger priorities or just had an if-it-ain't-broke-don't-fix-it mentality -- that they're about to find themselves with a bunch of unsupported code."

Gartner estimates that there are easily 14 billion lines of VB6 code extant in the enterprise, and the cost of migrating that code is likely to run to about $11 billion over the next 10 years.

By-the-Numbers

14 billion: Lines of VB6 code extant in the enterprise

$11 billion: Cost of migrating that code over the next 10 years

15: Potential number of years some VB code may be able to run unchanged

85: Percentage of developers using VB likely to migrate to .NET

Source: Gartner Inc.
(rough estimates by analyst)

Runtime Risk
But Driver says that the VB6 panic is "a bit of a Y2K issue." In other words, all that VB6 code may well run unchanged for many years into the future with no trouble at all.

"It could run another 15 years," Driver tells RDN, "or it could crash in six months. We just don't know. The reality is the chances of something going catastrophically wrong in the next two to four years are pretty low. The problem is this code is about to be unsupported."

The worst-case scenario for most organizations, he says, is that the code won't run in a future version of Microsoft's operating systems. Making things more confusing, Driver observes, is Microsoft's announced plan to support the VB6 runtime through Longhorn. That means, in theory, that an application built and running today should continue to run for the next 10 years.

"The problem with that theory is that it assumes that the application is feature-complete and defect-free," Driver says, "which is something I've never seen. There are cases, in fact, where Microsoft could fix the runtime, while something like a design pattern or security issue could require you to go back and change the code, even though the runtime is working."

Continued Support
Jeffrey Hammond, Analyst, Forrester Research Inc.In fact, Microsoft intends to support the VB6 runtime for the full lifetime of Windows Vista -- five years of mainstream support followed by five years of extended support -- and will continue to support the runtime on Windows 2000, Windows XP and Windows Server 2003 for the support lifetime of those operating systems. That means, says Forrester analyst Jeffrey Hammond, that with Vista, VB's runtime future is assured through 2017.

The continued VB runtime support on Vista should relieve some of the pressure on many enterprise IT shops, Hammond says. It provides a little breathing room and time to plan an incremental migration strategy. Best of all, a growing selection of conversion tools and service offerings are emerging that are likely to keep migration costs down.

Hammond doesn't suggest that managers put off their migration planning. He urges dev managers to take action during the next three to five years "to retire what will become an increasingly untenable and high-maintenance code base."

"The bottom line," he says, "is that .NET is the future of all things Windows, whether you like it or not. And if you're going to maintain any sort of support for Vista and beyond, you have to move to .NET."

About the Author

John K. Waters is the editor in chief of a number of Converge360.com sites, with a focus on high-end development, AI and future tech. He's been writing about cutting-edge technologies and culture of Silicon Valley for more than two decades, and he's written more than a dozen books. He also co-scripted the documentary film Silicon Valley: A 100 Year Renaissance, which aired on PBS.  He can be reached at [email protected].

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube