虽然已经发布了接近十年，Visual Basic 6 仍旧广泛应用于很多公司中的 IT 部门中。考虑到很多当前正在使用的应用程序甚至已经找不到源代码，我们必须仔细考虑将其升级至 Windows Vista 或 Server 2008 的步骤。为了能够让升级更加简单，微软公司为 VB 6 应用程序提出了一种名为“It Just Works”的策略。微软公司宣称，大多数 VB 6 应用程序应该可以直接运行于最新的操作系统上。所有需要的新版本 DLL 均会预装于操作系统中，或者可以由开发者进行分发。分发 DLL 的模式与在旧版本操作系统上的方法完全一致。若想了解更多，请查看 MSDN 上的这份图表。
32 位 Windows 操作系统仍将以“Custom Support”的方式继续支持 Visual Basic 6 的集成开发环境，Elise Peterson 这样介绍：
对于任何购买过 Visual Basic 6 IDE 的开发者来说，都将会得到继续的支持。Custom Support 计划是为那些需要得到早先版本产品（例如 Windows NT 4 和 Visual Basic 6 IDE）继续支持的 Premier Support 用户提供的。VB 6 的运行时仍将得到完整的支持，因为它也属于 Windows Vista 和 Windows Server 2008 的一部分。产品应用程序和组件也将在 Windows Vista 和 Windows Server 2008 的生命周期内得到支持。
我们针对某些细节方面对 Paul Yuknewicz 进行了采访。 你曾说到 VB 开发团队将接手管理并维护 VB6 开发者经常用到的一些组件，例如 comctl32.ocx 和 richtx32.ocx 等。能不能解释一下为什么要作出这样的决定呢？
在 Windows Vista 发布时，VB 开发团队曾经承诺通过“It Just Works”策略在该操作系统上继续支持 VB 6 应用程序。不过仍然有很多客户说，VB 6 IDE 的控件目录（\CAB）中包含的那些组件对于他们的应用程序来说也非常重要，且不知道我们是否会在 2008 年 4 月后继续为其提供支持。考虑到若是不能让这些 VB6 应用程序在 Vista 上运行得如同在 XP 上一样，那么这也谈不上什么“It Just Works”。因此，这样的决定有助于澄清我们对 VB 支持的态度——我们会一直为现有的应用程序提供支持。
这些组件一直以来都属于 VB 6，因此也就并不存在“应不应该做这些”这样的疑问。我们应该考虑的是“如何做得更好，且在 2008 年 4 月之后又该如何继续提供支持”。
在联系这些组件的原作者时，他们是倾向于保护这些代码，还是希望你们能够接管过去呢？
这两种情况都不是，真的。对于少数一些不属于 VB 开发团队的组件，原开发者已经不再有兴趣继续维护，所以这似乎变成了“无主”的东西。在与这些开发团队联系时，我们一般会看到两种回应。第一种是“哦，我们都不知道有多少人正使用着这些组件，又如何对他们进行支持呢？”。第二种是“实际上我们已经开发了一个最新的版本，能够与旧版本保持向下兼容。因此客户应该尝试使用这个新版本”。
你们需要为了支持 Server 2008 而开发一些新功能吗？（如果需要的话，用户又将如何使用呢？）
不需要。大多数情况下，这些组件都是简单地将 DLL 封装成为 ActiveX 控件，以便 VB6 开发者使用。这并不算是什么复杂的代码，且考虑到 Windows Vista 和 Windows Server 2008 已经支持这些 DLL，其核心的功能更不算什么问题。其实，Windows 开发团队已经为我们做好了绝大多数事情，我们所做的只不过是让 VB6 的开发者在使用时更加简单而已。
你觉得是否需要通过一个新的 VB6 Service Pack 来对未来的操作系统提供支持呢？
VB6 现在已经非常稳定——在过去的十年中发布了 6 个 Service Pack。因此我感觉不再需要什么额外的 Service Pack 了。
你觉得这个策略算是微软公司在 Server 2008 以及后续操作系统中对 VB6 以及 VB6/VB.NET 支持的一种削弱么？
不要忘记：微软公司将会对 Windows Server 2008 提供十年的支持——因此在同样的时间内也仍将支持 VB6 运行时。对 VB6 提供 20 年的支持——这是一个非常负责任的承诺。
查看英文原文： On the “It Just Works” Policy for VB 6 and Windows Vista/Server 2008
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论