前微软架构师怒揭Windows GUI混乱：14次转向、17条路线，一群聪明人做出了愚蠢的决定

如果你曾在 Windows 平台上做过开发，大概率都经历过类似的困惑：框架很多，路线各异，但就是没有一个“明确答案”。这些年，从 Win32 到 WPF，从 Silverlight 到 UWP，再到今天的 WinUI 和 MAUI，技术一轮轮更迭，方向却始终摇摆不定。

这其中究竟是微软的技术战略问题，还是有其他原因？

近日，前微软技术研究员、Office AI 架构师 Jeffrey Snover 带来了一篇长文，以亲历者的视角，把过去三十多年 Windows GUI 技术演进中的关键节点一一拆开，讲清楚问题是如何一步步积累、失控，并最终演变成今天这个“百花齐放却无所适从”的局面。

他直言，很多技术的兴衰，并非源自技术本身，而是内部团队的权力博弈、开发者大会上对尚未成熟平台的过早押注，或者一次突如其来的商业战略转向，把开发者直接“晾在一边”。

让开发者在十四年间的十四次转向，提供了 17 种路径、五种编程语言、三种渲染思路，这样的局面，就是一群聪明人，做出了愚蠢的决定。

几年前，我参加了一场开发者会议。有人抛出了一个看似再简单不过的问题：“如果要做一个新的 Windows 桌面应用，应该选哪个框架？”

现场一片沉默。过了好一会，才有人提了 WPF，另一个人说用 WinUI 3，还有人反问要不要干脆用 Electron。争论之下，讨论的话题很快就跑偏了，直到最后这个问题也没能得到答案。

事实上，这段沉默，本身就是答案。而这个问题的根源，可以追溯到三十多年前。

当一个平台连“我该怎么做 UI”这种问题都无法在十秒内给出清晰答案时，它其实已经辜负了开发者。没有任何借口。

Windows 上一次给出明确答案是什么时候？

1988 年，Charles Petzold 出版了《Programming Windows》。全书 852 页，用 C 语言讲解 Win16 API。尽管内容厚重，但它代表了一件极其难得的事情：关于“如何开发 Windows 应用”，它给出了一个统一、清晰且权威的答案。

在业内，我们将这种情况称之为“策略”。

随后出现的 Win32 体系更庞大，但依然保持一致性：消息循环、窗口过程、GDI。虽然当时它的思维模型多少有点古怪，但终归只有这一套模型。Petzold 把它讲清楚了。这就像 Windows 世界里的“F=ma”公式：简单、强大。你学会它，用它，就能做出想要的成果。

清晰明了就是最好的情况！一个操作系统、一套 API、一种语言、一本书。没有人争论托管代码的替代方案，没有委员会反复拉扯。只有 Win32 和 Petzold，而且它确实奏效。这更像“物理学”，而不是“化学”——不是那种“在特定元素周期表的一小块区域才成立、还得满足特定压力、温度，甚至月亮位置都要刚好”的复杂体系。

接下来发生的事情，可以说是一堂典型案例：一家拥有顶尖人才和雄厚资源的公司，是如何在三十年时间里，因为优化错了方向，搞出一连串混乱局面的。

换句话说，就是一群聪明人，做出了愚蠢的决定。

面向对象的狂热幻象（1992–2000）

Win32 确实存在不少局限，于是微软做了它一贯会做的事：在开发者大会上推出“新东西”。而且不是一个，是一堆。

MFC（1992）用 C++ 封装了 Win32。如果说 Win32 已经不够优雅，那 MFC 就像是给 Win32 穿了一件由更多“西装”拼出来的西装——复杂到有点滑稽。

随后出现了 OLE、COM、ActiveX。这些东西本质上都不是 GUI 框架，而是组件模型，但它们渗透进了 Windows 开发的每一个角落，引入了一种认知复杂度。

我至今记得自己在 90 年代末参加过一场会议，整整一个小时都在试图搞清楚 OLE 文档、COM 对象和 ActiveX 控件之间的区别。那一整场，我看着台上的讲者，感觉就像他嘴里挂着一截老鼠尾巴——完全无法理解他在说什么。

微软当时并没有提供一个连贯的整体叙事，它只是不断推出各种技术“零件”，然后让开发者自己去拼出一套体系。

这就是典型的“发布会主旨演讲灾难”——微软优化的是高管在台上如何讲得让人惊艳，而不是开发者和用户最终能不能真正成功。

PDC 2003：一个自我吞噬的愿景

在 2003 年的 PDC 大会上，微软发布了 Longhorn——可以说，这是它曾经向开发者展示过的最具吸引力的技术愿景之一。

Longhorn 由三大支柱构成：

WinFS（关系型文件系统）

Indigo（统一通信框架

Avalon，后来演变为 WPF——一个基于 GPU 加速、矢量化的 UI 子系统，由名为 XAML 的声明式 XML 语言驱动。开发者看到 Avalon 的演示几乎沸腾，这个方向本身没有问题。

但用 Jim Allchin 在 2004 年 1 月内部备忘录中的话来说，这个项目“就是一头猪”。

到了 2004 年 8 月，微软宣布全面重置开发：推倒重来，从 Server 2003 的代码库重新起步。重置之后，管理层还下达了一条几乎没有公开的指令：Windows 中禁止使用任何托管代码。所有新代码一律使用 C++。WPF 最终会随 Vista 发布，但 Windows 自身的外壳却不会使用它。

Windows 团队对 .NET 的怨气，从此再也没有消散。

在他们看来，押注一个全新的托管代码框架，直接导致了公司历史上最尴尬的一次失败。这种情绪，演变成了一场持续了十三年的“体制内内战”：Windows 团队对抗 .NET 团队。最终的结果是——WPF 被边缘化，Silverlight 被放弃，UWP 走向失败，也造就了今天这个一团乱麻的 Windows GUI 生态。

Silverlight：模式就此形成（2007–2010）

WPF 在 2006 年末正式发布。它相当惊艳——XAML、硬件加速渲染、真正可用的数据绑定。如果当时微软把它确立为“唯一答案”，并持续坚定投入，后面的故事也许会完全不同。

但 2007 年，微软推出了 Silverlight：一个精简版的浏览器插件，用来对抗 Flash。它跨平台、优雅，同时还是 Windows Phone 的技术基础。大约在 2010 年前后，它看起来像是富客户端的未来。

然而在 MIX 2010 的一次问答环节中，一位微软高管却表示：Silverlight 并不是一个跨平台战略，它的重点在 Windows Phone。HTML5 才是新的方向。而 Silverlight 团队事先对此毫不知情。那些把核心业务应用押在 Silverlight 上的开发者，也是通过这场现场问答才第一次听说这件事。

Silverlight 并不是死于技术失败。技术本身没有问题。它死于一次商业战略决策，而开发者是最后才知道的人。

记住这个模式，后面还会反复出现。

Metro 的焦虑与“两条战线”的内耗（2012）

当时，Apple 已经卖出了 2 亿部 iPhone，iPad 也在蚕食 PC 市场。微软的回应是 Windows 8 和 Metro——一个以触控优先为核心的运行时 WinRT，而且刻意不基于 .NET 构建。

还记得 Windows 团队对 .NET 的怨气吗？这里就是它的体现：WinRT 是一个原生 C++ 运行时，直接与 WPF、WinForms，以及开发者过去十年在 .NET 上的投入切割开来。

更混乱的是，当时微软内部其实同时在讲两套完全不同的故事：Windows 团队在推进 WinRT，而 .NET 团队还在继续推广 WPF。不同的办公楼、不同的副总裁、不同的路线图。

开发者在 2012 年的 Build 开发者大会上听到的是什么？未来属于 WinRT，同时 HTML + JS 是一等公民，同时 .NET 仍然可用，同时 C++ 强势回归，同时你应该写 Metro 应用，同时你的 WPF 代码也还能正常运行。

这根本不是什么战略，而是一场“饥饿游戏”的竞技场——六支队伍同时在争夺你的注意力。

企业开发者很快做出了选择：他们看了一眼 UWP 的沙盒限制、必须通过应用商店分发的要求，以及缺失的 Win32 API，然后转身离开。

这个本该带他们进入“现代应用时代”的框架，实际上却是为一个从未真正成立的平板应用商店而设计的。

UWP 与 WinUI 的蔓延（2015–至今）

Windows 10 带来了 UWP（Universal Windows Platform）：一次编写，多端运行，覆盖 PC、手机、Xbox、HoloLens。表面上看很美好，问题在于：Windows Phone 正在走向消亡，而微软自家的旗舰应用（Office、Visual Studio，甚至 Windows 自身的外壳）都没有采用 UWP。

即使没人公开谈论，这个信息已经足够明显了。

当 UWP 推进受阻之后，官方给出的答案变成了：“看情况”。新应用用 UWP，旧应用继续用 WPF，通过 XAML Islands 引入新 API，等待 WinUI 3，同时 UWP 里还有专用的 WinUI 2，再加上 Project Reunion 会解决一切——不过它后来改名叫 Windows App SDK，而且依然不能完全替代 UWP。

同时一群聪明人，做着让人费解的决策。这更像是技术版的布朗运动——无规则、无方向的随机游走。

Project Reunion / WinUI 3 确实代表了一定程度的进步。但你也可以反过来问一句：这个问题为什么一开始会存在？UWP 的控件之所以与操作系统深度绑定，是因为它们归 Windows 团队所有，而不是 .NET 团队，也不是开发工具团队。Project Reunion，本质上是一个组织结构问题的“技术化补丁”。

有开发者在 2024 年这样总结自己的经历：“我一路跟着微软的各种变化走过来：UAP、UWP、C++/CX 被 C++/WinRT 取代却没有配套工具、XAML Islands、XAML Direct、Project Reunion、WinAppSDK 的重启，还有 WinUI 2.0 和 3.0 之间的混乱切换……”

十四年，十四次转向。这个人，应该先拿一枚勋章，然后再得到一句道歉。

没有管理员的“动物园”

下面这些，都是今天仍然在 Windows 上实际存在、被使用的 GUI 技术：

微软原生框架：

Win32（1985）—— 仍在，还被广泛使用。Petzold 的那本书到现在依然适用。

MFC（1992）—— 基于 Win32 的 C++ 封装。进入维护期，在企业软件和 CAD 领域依然活跃。

WinForms（2002）—— .NET 对 Win32 的封装。“可以用，但不推荐。”不过做数据录入界面依然是最快的选择。

WPF（2006）—— 基于 XAML、由 DirectX 渲染、已开源。但微软已经不再新增投入。

WinUI 3 / Windows App SDK（2021）—— 被称为“现代答案”，但路线仍不明朗。

MAUI（2022）—— Xamarin.Forms 的跨平台继任者，也是 .NET 团队当前押注的方向。

微软的 Web 混合方案：

Blazor Hybrid —— 在原生 WebView 中运行 .NET 的 Razor 组件。

WebView2 —— 在 Win32 / WinForms / WPF 应用中嵌入 Chromium。

第三方方案：

Electron —— Chromium + Node.js。VS Code、Slack、Discord 都在用。如今 Windows 上部署最广泛的桌面 GUI 技术，但和微软没什么关系。

Flutter（Google）—— 使用 Dart，自带渲染引擎，跨平台。

Tauri —— 基于 Rust 的轻量级 Electron 替代方案。

Qt —— 支持 C++ / Python / JavaScript，严肃的跨平台解决方案。

React Native for Windows —— 微软支持的 Facebook 移动框架移植版。

Avalonia —— 开源的“WPF 精神续作”。被 JetBrains、GitHub、Unity 等采用——这些开发者已经不再等待微软。

Uno Platform —— 把 WinUI API 带到所有平台上，在某种意义上比微软自己更坚持 WinUI。

Delphi / RAD Studio —— 还活着，还很高效，在垂直行业软件中依然占有一席之地。

Java Swing / JavaFX —— 是的，还在生产环境中运行。企业世界从不轻易遗忘。

一共十七种路径，五种编程语言，三种渲染思路。这已经不能叫“平台”了。也许我没法给 “boof-a-rama” 下一个精确定义，但我一眼就能认出来。

教训

几乎所有失败的 GUI 尝试，都可以追溯到三类原因之一：内部团队的权力博弈（Windows vs .NET）、在开发者大会上过早押注尚未成熟的平台（Metro、UWP），或者一次突如其来的商业战略转向，把开发者直接“晾在一边”（Silverlight）。

这些都不是技术失败。很多技术本身其实是优秀的——WPF 是好的，Silverlight 是好的，XAML 也是好的。

真正失败的，是组织本身。

要么你有一套完整、可信的“成功路径”理论，覆盖从采用、投入、维护到迁移的整个生命周期；要么你就只是在做一场开发者大会的主旨演讲。

前者是战略，后者只是三十年的混乱循环。

Charles Petzold 曾为了跟上微软每一次推出的新东西，撰写了六个版本的《Programming Windows》。最终，第六版停在了 Windows 8 的 WinRT，也就是 2012 年。

这事我不怪他。

原文：https://www.jsnover.com/blog/2026/03/13/microsoft-hasnt-had-a-coherent-gui-strategy-since-petzold/

本文来自微信公众号“CSDN”，作者：Jeffrey Snover；责编：苏宓 36氪经授权发布。