Visual Basic 6 in the year2026: A call to Microsoft

作为一种编程语言，C# 绝不比 VB6 差，甚至不比 VB.NET 差。

但是：对于 VB6 开发人员来说，.NET 开发环境就像是回到了石器时代：

1. 它缺乏神奇的调试功能，而 VB6 中的 "实时编程 "功能则是编程的真正助推器：你从草稿开始，然后在运行时对其进行优化。
2. .NET将数百种技术整合在一起，但过多的界面让任何新手或转换者从一开始就望而却步，而且熟悉集成开发环境的学习曲线非常大。
3. .NET集成开发环境的响应速度要慢得多，启动一个小的Hello World应用程序可能要花上10秒的编译时间才能启动一个简单的程序...
4. .NET IDE 似乎非常耗费资源。在拥有 250GB 硬盘空间的 Surface 笔记本电脑上快速安装 .NET 开发环境，在释放所需的资源时很快就会变得像运行吐痰路线一样。

我呼吁微软：VB6 必须成为开放源代码，这样它才能被社区进一步开发，并转移到 2026 年。

VB6 在 2026 年继续存在

社区从未放弃 Visual Basic6。Kr00l将 VB6 中常用的 Microsoft 通用控件移植到了 2026 中，并创建了完全支持 DPI 和 Unicode/UTF-8 的相同组件。

TwinBasic正在发展成为一个可启动的 64 位编译器，甚至可用于现有程序。该社区的做法值得称赞，也极具雄心壮志，尤其是因为没有人能获得 VB6 源代码，该社区必须从头开始开发一切。

不幸的是，这种方法实际上野心太大，值得一问：我们究竟还有什么其他选择？

VB6 的许多弱点，如真正的多线程，都可以在 2026 年通过附加的 Rust 组件来解决。

Visual Basic 中的 OOP 程度是一种巧妙的折衷，既降低了复杂性，又可选择使用类作为方法和数据的容器，从而真正提高了编程效率。这种方法不应该有任何改变。

VB6 集成开发环境的安装程序可以而且应该完全重建，例如使用Inno Setup。

完整的 DPIAwareness、完整的 UTF8 功能甚至 64 位编译器都可以直接内置到 VB6 源代码中。

如果 VB6 仍在调用 Win32 API 中的 Ansi 方法（如 WriteTextA），我们可以用支持 UTF8 的 W 方法（WriteTextW）来替代。

我们社区将接手这项任务，并将 Visual Basic 6 的巧妙方法延续到 2026 年。因为现在没有一个以前的 VB6 爱好者真正热衷于使用 Visual Basic .NET。

微软公司必须承认：终止 VB6 并将 .NET 定位为其继承者的决定是失败的。

许多剩余的 VB6 开发人员将不得不慢慢调整自己的方向，失去耐心，然后缓慢但坚定地转向 Linux 和 Rust。

或者，微软将发布 Visual Basic 6 源代码，而我们，社区，将把这一出色的 Windows 开发环境带入 2026 年。

对于社区、开发者、用户甚至整个技术领域来说，后者都将是一个巨大的胜利。

最后但并非最不重要的一点是，这对微软来说也是一大利好，因为将Visual Basic 6的源代码作为开放源代码提供的决定还将提高微软的声誉，让许多粉丝和开发者重新回到微软，并将他们与微软的生态系统绑定在一起。

我认为这将是微软的一次重大胜利。