VB6 Visual Basic 6 API 是否适用于 Windows 8？答案

【问题标题】：Does VB6 VisualBasic6 API's work on Windows 8?VB6 Visual Basic 6 API 是否适用于 Windows 8？
【发布时间】：2012-11-11 21:38:32
【问题描述】：

是否只有基本的 VB6 应用程序在 WIN8 上运行？是否有任何 API 在使用中有所不同，例如 GDI+、Keyhooks、FileSystem 或 RtlMoveMemory API。

VB6 是 x86，Win8 是 x64。

我已经读过： VB6 Running on Windows 8?

【问题讨论】：

Windows 8 也可作为 x86 使用

标签： windows vb.net vb6

【解决方案1】：

Windows 8 不会更改 Windows 桌面应用程序的基本 API。（当然 Windows RT 除外）

Windows 的未来版本也不会；对这些 API 的任何更改都会破坏与所有现有应用程序的兼容性。

【讨论】：

有很多变化，比如任何东西的接口。您确定 VB6 x86 应用程序可以与 x64 Win8 API 一起使用吗？
@Nasenbaer：你在说什么？他在询问基本的 Windows API。
每个 VB6 应用程序都是 x86，每个 Win8 都是 x64。我需要记住的事情。而且在 Win8 中也发生了一些变化，与 Win98、WinXP、Win7 不同……我不知道，但 API 可能也发生了变化，或者不再受支持？
@Nasenbaer：错误； Windows 8 也可作为 x86 使用。此外，Windows x64 仍然可以运行 x86 应用程序。而且，Windows 8 不会破坏兼容性。

【解决方案2】：

我们刚刚开始在 Windows 8 x64 上测试我们的 VB6 应用程序。该应用程序庞大而复杂。一切似乎都可以正常工作，甚至是较旧的第三方 OCX 控件等。ADO/MDAC 可以很好地与各种版本的 SQL Server 配合使用。有很多 Win32 API 调用似乎也可以正常工作。我们还能够在 Windows 8 x64 上安装 VB6 IDE 以进行测试和调试。

不过，第一个问题是一个通用的 50003 错误和一条消息，说它无法创建主应用程序表单或类似的东西。进一步调查显示，出于某种原因，Windows 8 不喜欢某些嵌入在表单中的图标（它们存储在表单随附的 .frx 文件中，并在编译时嵌入到 .exe 中）。看来它可能与具有透明背景的图标有关。

该应用程序大约有。 100 个受影响的表格。解决此问题后，该应用程序似乎可以正常工作。但这件事破坏了我们在 Windows 7 上运行良好的分发可执行文件（以及 Vista 和 XP 以及所有服务器版本，以及在 2000、Win98 和 Win95 上运行的旧版本）。它可以很容易地修复，但我们希望不必做任何事情。叹。

如果其他人看到此内容或有任何提示或建议，我会很感兴趣。

附： @Hans Passant，Windows 7 SP1 ADO 问题已通过 KB2640696 修复。

【讨论】：

找出问题所在。某些表单嵌入了 16 位颜色深度图标。将它们更改为具有 256 色和 RBG/A 并且似乎可以修复它。希望我们不需要这样做。

【解决方案3】：

保持旧的 VB6 程序运行肯定越来越难。 Windows 7 SP1 部署了一个 long overdue update to ADO，它将阻止旧的 VB6 dbase 应用程序工作。 MSCOMCTL.OCX this year 有两个重要的安全补丁，其中一个更改了 guid。

虽然您可以通过跳过这些更新来让旧机器继续运行旧的 VB6 应用程序，但 Windows 8 将让它们就位并且您无法恢复。您必须在具有这些更新的机器上重建您的应用程序，以便它使用新的类型库。如果这不是一个选项，那么虚拟机就是让它继续运行的方法。但是，我还没有看到对 Virtual XP Mode 的支持。

【讨论】：

Win8 上的 x86 ADO 类型库可以向后兼容，所以他们基本上撤消/修复了 Win7 SP1 所做的更改。 Win7 SP2 也可能会在 Win7 上恢复 ADO 类型库。
而且 MSCOMCTL.OCX 从未作为任何 Windows 版本的一部分安装，所以那里没有问题。如果您将自 2008 年以来他们一直在尝试并失败的那些多次破坏的“安全汇总”尝试安装到您的开发机器上，并且您正在从您的开发机器部署 OCX 的实时副本（a no-no) 而不是来自 Redist 文件夹或标准合并模块。
@Bob：啊哈，如果 VB6 应用程序在开发机器上针对它的“好”版本进行编译，那么即使这些修补的 MSCOMCTL.OCX 在客户端机器上也可以正常工作？
损坏版本的 MSCOMCTL.OCX 进入客户端系统的唯一方法是有人在其中部署了它。一旦有人污染了机器，你自己的程序只有一次机会：一个孤立的装配。 Windows 更新不会将这些损坏的库推送给客户端，它们仅用作开发人员更新。可悲的是它们有缺陷。 ADO 与 Win7PS1 是不同的情况，涉及编译时使用的类型信息。如果您针对一个好的类型库进行编译，这些都不是问题。