自Petzold时代以来，微软就一直缺乏连贯的图形用户界面（GUI）策略

几年前，我和开发人员开会时，有人问了一个简单的问题：“对于新的 Windows 桌面应用程序来说，哪个框架最合适？”

一片死寂。有人提议用WPF，有人说用WinUI 3，还有人问是不是应该直接用Electron。会议就此偏离主题，我们最终也没能回答这个问题。

那份沉默本身就是故事。而这个故事可以追溯到三十多年前。

如果一个平台无法在十秒钟内回答“我应该如何构建用户界面？”这个问题，那么它就辜负了开发者。就这么简单。

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

1988年，查尔斯·佩措尔德出版了《Windows编程》，共852页，内容涵盖Win16 API的C语言编写。尽管篇幅庞大，但它却代表着一项非凡的成就：它为如何编写Windows应用程序提供了一个单一、连贯且权威的答案。在业内，我们称之为“策略”。

随后的Win32规模更大，但依然逻辑清晰。消息循环、窗口过程、GDI。虽然当时的思维模型有点古怪，但它毕竟是一个统一的思维模型。佩措尔德对此进行了解释。它就像Windows的F=MA公式：简单、强大。你学会了它，运用了它，你便获得了成功。

清晰明了是你的朋友！一个操作系统，一个API，一种语言，一本书。没有委员会讨论托管代码的替代方案。只有Win32和佩措尔德，而且它行之有效。这是物理学，不是化学（这行得通，但仅限于元素周期表的这一部分。而且仅在这些压力下。而且仅在这个温度下。而且仅当月亮位于木星的第七宫时才有效）。

接下来发生的事情堪称一堂经典的课，它展现了一家拥有杰出人才和雄厚资源的公司如何因为优化方向错误而导致长达三十年的彻底失败。换句话说，就是一群才华横溢的人做了蠢事。

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

Win32 的确存在一些局限性，所以微软做了微软惯常的做法：在开发者大会上发布了一些新功能。而且不止一个。

MFC（1992 年）用 C++ 封装了 Win32。如果说 Win32 不够优雅，那么 MFC 就是穿着由其他燕尾服拼接而成的燕尾服的 Win32。随后出现了 OLE、COM 和 ActiveX。这些都不是真正意义上的 GUI 框架——它们是组件架构——但它们渗透到 Windows 开发的方方面面，引入了一种认知复杂性，以至于读克尔凯郭尔的作品都显得像读海明威的作品一样轻松。

九十年代末，我参加了一个会议，试图弄明白 OLE 文档、COM 对象和 ActiveX 控件之间的区别。整整一个小时，我都一脸懵逼地看着演讲者，就好像他嘴里叼着条老鼠尾巴似的。

微软并没有讲述一个连贯的故事，而是在兜售技术碎片，让开发者自己去摸索故事的内核。这就是大会主题演讲的糟糕之处——微软只注重高管在主题演讲中给人留下深刻印象，而忽略了用户和开发者的实际成功。

PDC 2003 和吞噬自身的愿景

在 2003 年的 PDC 大会上，微软发布了 Longhorn——这无疑是该公司向开发者展示过的最具吸引力的技术愿景之一。Longhorn 由三大支柱构成：WinFS（关系型文件系统）、Indigo（统一通信）以及 Avalon（后来的 WPF）——一个基于矢量、GPU 加速的 UI 子系统，由名为 XAML 的声明式 XML 语言驱动。开发者们观看了 Avalon 的演示后欣喜若狂。事实证明，这个愿景是正确的。

用吉姆·奥尔钦在 2004 年 1 月的内部备忘录中的话来说，它也是“一头猪”。

2004 年 8 月，微软宣布彻底重置开发流程。所有旧版本都被弃用，一切都从 Server 2003 的代码库重新开始。重置之后，领导层悄悄下达了一项指令：Windows 中禁止使用任何托管代码。所有新代码都必须用 C++ 编写。WPF 会与 Vista 一同发布，但 Windows 系统本身不会使用它。

Windows团队对.NET的怨恨从未消散。在他们看来，押注于一个新的托管代码框架，导致了公司历史上最令人难堪的失败。这种怨恨引发了Windows团队和.NET团队之间长达十三年的内战，最终导致WPF被弃用，Silverlight走向衰亡，UWP走向毁灭，并造就了我们今天看到的混乱不堪的GUI生态系统。

Silverlight：模式的建立（2007–2010）

WPF于2006年末发布。它非常出色——XAML、硬件加速渲染、真正的数据绑定。如果微软当时将其视为最终解决方案并持续投入，故事的结局或许会截然不同。然而，在2007年，他们推出了Silverlight：一个精简的浏览器插件，旨在与Flash竞争，它具有跨平台、优雅等优点，并且是Windows Phone的基础。到了2010年左右，它似乎代表了富客户端的未来。

在2010年的MIX大会上，一位微软高管在问答环节中表示，Silverlight并非跨平台战略，而是针对Windows Phone的。HTML5才是当时的战略方向。Silverlight团队对此毫不知情。那些将业务线应用程序押注在Silverlight上的开发者，也是在大会问答环节中才得知这一消息的。

Silverlight 的消亡并非源于技术故障，技术本身并无问题。它的消亡是由于一项商业战略决策，而开发者们却是最后才知晓此事的人。

记住这个规律，我们还会再遇到。

地铁恐慌与双队之战（2012）

苹果公司售出了2亿部iPhone。iPad蚕食了PC的市场份额。微软的应对之策是Windows 8和Metro——一个名为WinRT的触控优先运行时环境，它刻意没有基于.NET构建。还记得Windows团队当时的怨气吗？现在它体现在这里了。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 引入了通用 Windows 平台 (UWP)——一次编写，即可在 PC、手机、Xbox 和 HoloLens 上运行。纸面上看起来很有吸引力。但问题是：Windows Phone 正在走向衰落，而微软自家的旗舰应用——Office、Visual Studio 以及 Shell 本身——都没有使用 UWP。即使没有人公开谈论，这个信息也已经很明显了。

UWP 停滞不前时，官方的回答是“视情况而定”。新应用可以使用 UWP，现有应用可以继续使用 WPF，可以通过 XAML Islands 添加现代 API，也可以等待 WinUI 3，但 WinUI 2 也已经专门针对 UWP 开发了，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）——依然存在，依然在使用。佩措尔德的著作仍然适用。
MFC（1992）——基于Win32的C++封装库。维护模式。主要应用于企业和CAD领域。
WinForms (2002) – 基于 Win32 的 .NET 封装。“可用但不推荐。” 仍然是数据录入表单最快的选择。
WPF（2006 年）——基于 XAML，使用 DirectX 渲染，开源。微软没有进行新的投资。
WinUI 3 / Windows 应用 SDK (2021)——“现代”解决方案。路线图尚不明朗。
MAUI（2022）——Xamarin.Forms 的跨平台继任者。.NET 团队目前的重点项目。

微软 Web 混合：

Blazor Hybrid – 在原生 WebView 中使用 .NET Razor 组件。
WebView2 – 将 Chromium 嵌入到 Win32/WinForms/WPF 应用程序中。

第三者：

Electron ——Chromium + Node.js。VS Code、Slack、Discord。目前Windows平台上应用最广泛的桌面图形用户界面技术——而它与微软毫无关系。
Flutter（谷歌）——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 与 .NET 之争）、开发者大会上的公告导致过早押注某个平台（Metro、UWP），或者业务战略的突然转变导致开发人员毫无预警地被孤立（Silverlight）。这些都不是技术上的失败。技术本身往往是优秀的——WPF 优秀，Silverlight 优秀，XAML 也优秀。组织层面的失败在于产品本身。

要么你有一个涵盖整个生命周期（采用、投资、维护和迁移）的合理成功理论，要么你有一个开发者大会主题演讲。

一种是战略，另一种是长达三十年的哗众取宠。

查尔斯·佩措尔德为了跟上微软发布的每一项新技术，撰写了六版《Windows编程》。他在第六版之后就停止了写作，第六版涵盖了Windows 8的WinRT技术。那是2012年。

我不怪他。