Classic VB Corner

Microsoft's VB6 Support Strategy?

After years neglecting the VB6 community, Microsoft seems to be missing something. Us!

A couple months ago, it came to my attention that numerous tools and samples for VB5/6 had gone AWOL from Microsoft's Web site. Thankfully, I'd squirreled them away on my own Web site, and also on numerous other backup media. I dropped a note to a friend in Redmond, who put me in touch with someone on the VB team.

I think the VB team was actually in the process of building their new Visual Basic 6.0 Resource Center site on MSDN at the time, as they were apparently excited to find that the backups still existed and they could restore the files directly.

I started prowling around the rest of the new support site, which prominently displays a link to the familiar Support Statement for Visual Basic 6.0 on Windows. I also found links to the documentation, which was nice. (It would be even nicer if they would just release the October 2001 MSDN libraries into the wild, as a free download, wouldn't it?)

But what really caught my eye was another very prominent link: Video: What is Microsoft's VB6 Strategy?

Unfortunately, if you click that link, you will find that Microsoft marketing may be standing in the way of you actually receiving the message they want to convey. The linked video requires the Silverlight runtime, which is not ubiquitously deployed. Fortunately, if you go directly to the Channel 9 copy of the same video, you will find WMV, WMA, MP3 and MP4 media format options below the video inset window. These won't force you to install yet another marketing misadventure.

Tale of the Video Tape
Cutting to the movie. Beth Massi is interviewing Paul Yuknewicz, who Beth calls "the guy in charge of Visual Basic 6." Paul opens with some nice words, but seems a bit down at having to say them. When asked if he could talk a little about the support strategy for VB6, he says, "Sure, yeah. Visual Basic 6, hugely important product and audience to us, y'know, if we could continue the magic of VB6 forever, I think we'd all be happy about that." The wistfulness isn't lost on this viewer, as Paul's eyes are cast downward.

Paul then mentions that a there's just a lot of VB6 code out there still, and seems to express regret over the initial convert-to-.NET strategy employed by Microsoft when Visual Fred was first rolling out. Beth asks whether the existing code was just too complex to migrate, and Paul replies that the number one reason he heard for people not migrating was that there was simply no business need or reason to undertake such an effort.

That's a pretty critical point. I remember stating it that way, or quite similarly, myself a few times over the last decade. He also thought that perhaps it was "just too hard" and "way too much work" for anyone to bother undertaking. So there we have it, far too hard to get nothing accomplished. Got it. This introduction consumed the first two minutes of the 23 minute video.

The next six minutes concentrate on the ongoing support for "the runtime and all the controls" through the Windows 7 lifetime. Paul talks about the runtime being a part of both Vista and Windows 7, so that's effectively five years of mainstream support plus five years of extended support from the date of release of each. You can almost see the (light-hearted) despair on his face when Beth points out that means he'll be talking about VB6 support in 2019.

The IDE is confirmed dead, even though it's really fast. "VB6 is still the product to beat in performance," Paul says in the video. You won't really hear much in this segment that you're not aware of already, except that "Microsoft had the draw the line" somewhere and Paul feels these decisions were right. "The runtime was the most important thing to keep running. If Microsoft makes a change and we cause a regression to your app, yep, that's a support issue you should talk to us about." Plenty of clarity there. Appreciated and accepted.

The middle segment turns to the marketing message. Paul moves to the whiteboard, and things go downhill from here. The ensuing 11 minutes provide an outline for migration. It turns out that the VB6 support strategy is to get people to move their code out of VB6! We learn that the "migration wizard" is now called the "upgrade wizard," for example, perhaps because migration sounds so much harder than upgrading? It still can't convert the code, of course, but there's another wizard that will now mark up your existing VB6 code to highlight things that just aren't supported in Visual Fred. Forewarned is forearmed, I suppose. I did run the new wizard against a project I recently offered here, and was mildly amused by the output.

In the final three-minute segment, Paul is asked to offer any other thoughts he may have to VB6 developers. He responds, "We miss you guys. ‹laughs› Um, y'know, we're looking for you.... "We really care about your assets continuing to run. That's the message. We love you guys. We miss you guys. There's some cool stuff going on in .NET, but take your time."

Gag me. I'm sorry, Paul seems like a really nice guy. He probably even feels this message is sincere. The rest of the video doesn't support this summary sentiment. Maybe he's speaking for the people involved, but he's certainly not speaking for Microsoft the Corporation at that point. Tough love may have its place, but I'd suggest that customer relations isn't it.

What about the #1 reason people didn't move in the first place? That was never addressed. No business need. So they clearly think we all take it as a given that .NET should be the final destination, or it's still a marketecture in pursuit of a market. The #2 reason for not migrating was that it was a lot of work to accomplish "nothing" (no business need, remember?), was given a few bullets on the whiteboard. They have new wizards that still don't manage to take away the "lots of work" part. Apparently, there are new interop ways that are "really low risk" so you "don't have to abandon your whole codebase to try to evolve it." Hmmmm.

COBOL of the 2020s
Almost as a parting thought, some clarifying insight is offered. There are apparently "several million" developers who are still using Classic VB. Given that Microsoft routinely tossed around numbers in the three-to-six million range, at the peak of Classic VB's popularity, that's a huge percentage of developers staying at home. Paul says that "as a stockholder" VB6 is very important to Microsoft, because converting "any percentage of several million" over to the new language would be very significant. This rings true. The renewed efforts at the VBRUN site make more sense in this light.

I'm very happy that the VB6 runtime is supported for the next decade. But I'm far from surprised. I've been calling VB6 the "COBOL of the 2020s" for some time, because its tentacles have reached deep into nearly every large institutional setting out there. Businesses run on Classic VB. Governments run on Classic VB. Just as the Microsoft Office team couldn't jettison VBA without risk of toppling the empire, neither can Microsoft expect corporations or governments to move to an operating system that doesn't support Classic VB code.

So are we at a stalemate? Perhaps for now. I do suspect the day will come when another company finally produces The Tool, likely one that supports platforms besides (or in addition to) Windows, which will attract the attention and loyalty of a great number of the Classic VB holdouts. When that day comes, we'll see Microsoft kick itself into gear, just as it did when Borland threatened the VB franchise with regular updates of Delphi in the early- to mid-1990s. Only then will we get more than promises of runtime support and flashy new "migration" wizards. Until then, I imagine they'll still be missing us.

I'll close by mentioning that I've been told many times that trust is highly overrated when dealing with companies like Microsoft. Probably so. But the loss of trust is something that doesn't go away. Until the Visual Fred debacle, Microsoft had never rendered any of their customer's data unusable. Not once. Why they did it first to the users of the world's most popular programming language ever, the product the company was founded upon and that may have had more impact on their overall corporate position than any other, is extremely puzzling.

I haven't heard any reason yet to consider letting them do it again. Have you?

About the Author

Karl E. Peterson wrote Q&A, Programming Techniques, and various other columns for VBPJ and VSM from 1995 onward, until Classic VB columns were dropped entirely in favor of other languages. Similarly, Karl was a Microsoft BASIC MVP from 1994 through 2005, until such community contributions were no longer deemed valuable. He is the author of VisualStudioMagazine.com's new Classic VB Corner column. You can contact him through his Web site if you'd like to suggest future topics for this column.

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