On the "It Just Works" Policy for VB 6 and Windows Vista/Server 2008

Posted by Jonathan Allen on Apr 29, 2008 06:46 AM

Community

.NET

Topics

Future Proofing

Tags

Windows Vista ,

VB 6 ,

Windows Server 2008

Though released nearly a decade ago, Visual Basic 6 still remains a cornerstone for the IT department of many companies. With so many line of business applications, many no longer with source code, in use, upgrade paths to Windows Vista and Server 2008 needs to be considered carefully.

The make the upgrade somewhat easier, Microsoft has committed to an "It Just Works" policy for VB 6 applications. Under this promise, most VB 6 applications should run as-is on the newer operating systems. Any updated DLLs needed will be either pre-installed on the OS or distributed by the developer. The distribution mode for a particular DLL will be the same as it was with older operating systems. For a complete list, consult the chart on MSDN.

The Visual Basic 6 IDE will continue to be supported on 32-bit versions of Windows as "Custom Support". Elise Peterson writes,

Extended support for the VB6 IDE was available to anyone who purchased the IDE. Custom support is a program available to our Premier Support customers who need ongoing support for legacy products such as Windows NT 4 and the VB6 IDE. The VB6 runtime remains in full, mainstream support since it is a part of Windows Vista and Windows Server 2008. Product applications and components will be supported as long as Windows Vista and Windows Server 2008 are supported.

We interviewed Paul Yuknewicz on some of the details.

You said the VB team took over the code base for components that VB 6 programmers often used such as comctl32.ocx and richtx32.ocx. Can you tell me how that decision was originally made?

When Windows Vista was released, the VB team was committed to what we called “it just works” support for VB6 applications on Windows Vista. Many of our customers, however, pointed out that critical components in the VB6 IDE’s controls folder (\CAB) are a core part of their running application and it was not clear if they had support when the Visual Basic 6 IDE left extended support a year later in April 2008. And if the experience for our customers’ VB6 applications running on Vista isn’t as seamless as on XP, then that’s not “it just works” support. This decision was made to clarify the outcome for these critical files and ensure we stand behind running applications.

These components had always been a part of Visual Basic 6, so there was never a question of “should we do this?” The questions we had to answer were “how do we do this, and how do we do it before April 2008?”

When you contacted the components original owners, were they protective of their code or eager for you to take it off their hands?

Neither, really. For the handful of components that were not already owned by the Visual Basic team, the original programmers from ‘96 or ‘98 had long since moved on, so no one was territorial. When we talked to these teams, we got one of two initial reactions. The first was ‘Wow, we had no idea how many of our customers depend on these components. How can we help?’ The second was ‘We actually have a more recent, improved version that’s backwards compatible with the old one. Customers should use the new one instead.’

Did you have to develop new versions in order to ensure they worked on Server 2008? (And if so, how do we get our hands on it?)

Not at all. In most cases, these components were simply lightweight wrappers that turned DLLs into ActiveX controls for easy consumption by VB6 developers. That’s not complex code, and considering that the DLLs were already supported on Windows Server 2008 and Windows Vista, the core functionality wasn’t even an issue. To put it another way, the Windows team does all the heavy lifting to keep this functionality up-to-date, and the components we’re supporting give VB6 developers easy access to it.

Do you foresee the need for a new VB6 service packs to support future operating systems?

This is a very stable code base, and six service packs have been issued in the decade since it was released, so I don’t foresee service packs to the VB6 runtime.

Would you consider this a stop-gap measurement or is Microsoft committed to keeping VB6 and VB6/VB.NET hybrid applications running post-Server 2008?

Don’t forget: Microsoft will support Windows Server 2008—and thus the VB6 runtime—for another decade. That totals two decades of support for Visual Basic 6--a very significant commitment.

• Older >