前微軟架構師怒揭Windows GUI混亂：14次轉向、17條路線，一群聰明人做出了愚蠢的決定

如果你曾在 Windows 平臺上做過開發，大概率都經歷過類似的困惑：框架很多，路線各異，但就是沒有一個“明確答案”。這些年，從 Win32 到 WPF，從 Silverlight 到 UWP，再到今天的 WinUI 和 MAUI，技術一輪輪更迭，方向卻始終搖擺不定。

這其中究竟是微軟的技術戰略問題，還是有其他原因？

近日，前微軟技術研究員、Office AI 架構師 Jeffrey Snover 帶來了一篇長文，以親歷者的視角，把過去三十多年 Windows GUI 技術演進中的關鍵節點一一拆開，講清楚問題是如何一步步積累、失控，并最終演變成今天這個“百花齊放卻無所適從”的局面。

他直言，很多技術的興衰，并非源自技術本身，而是內部團隊的權力博弈、開發者大會上對尚未成熟平臺的過早押注，或者一次突如其來的商業戰略轉向，把開發者直接“晾在一邊”。

讓開發者在十四年間的十四次轉向，提供了 17 種路徑、五種編程語言、三種渲染思路，這樣的局面，就是一群聰明人，做出了愚蠢的決定。

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

作者 | Jeffrey Snover 責編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

幾年前，我參加了一場開發者會議。有人拋出了一個看似再簡單不過的問題：“如果要做一個新的 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 年。

這事我不怪他。

【活動分享】"48 小時，與 50+ 位大廠技術決策者，共探 AI 落地真路徑。"奇點智能技術大會是由深耕多年的「全球機器學習技術大會」重磅升級而來。2026 奇點智能技術大會將于 4 月 17-18 日在上海環球港凱悅酒店正式召開，大會聚焦大模型技術演進、智能體系統工程、OpenClaw 生態實踐及 AI 行業落地等十二大專題板塊，特邀來自BAT、京東、微軟、小紅書等頭部企業的 50+ 位技術決策者分享實戰案例。旨在幫助技術管理者與一線 AI 落地人員規避選型風險、降低試錯成本、獲取可復用的工程方法論，真正實現 AI 技術的規模化落地與商業價值轉化。這不僅是一場技術的盛宴，更是決策者把握 2026 AI 拐點的戰略機會。