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

這其中究竟是微軟的技術(shù)戰(zhàn)略問題，還是有其他原因？

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

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

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

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

作者 | Jeffrey Snover 責編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

幾年前，我參加了一場開發(fā)者會議。有人拋出了一個看似再簡單不過的問題：“如果要做一個新的 Windows 桌面應用，應該選哪個框架？”

現(xiàn)場一片沉默。過了好一會，才有人提了 WPF，另一個人說用 WinUI 3，還有人反問要不要干脆用 Electron。爭論之下，討論的話題很快就跑偏了，直到最后這個問題也沒能得到答案。

事實上，這段沉默，本身就是答案。而這個問題的根源，可以追溯到三十多年前。

當一個平臺連“我該怎么做 UI”這種問題都無法在十秒內(nèi)給出清晰答案時，它其實已經(jīng)辜負了開發(fā)者。沒有任何借口。

Windows 上一次給出明確答案是什么時候？

1988 年，Charles Petzold 出版了《Programming Windows》。全書 852 頁，用 C 語言講解 Win16 API。盡管內(nèi)容厚重，但它代表了一件極其難得的事情：關(guān)于“如何開發(fā) Windows 應用”，它給出了一個統(tǒng)一、清晰且權(quán)威的答案。

在業(yè)內(nèi)，我們將這種情況稱之為“策略”。

隨后出現(xiàn)的 Win32 體系更龐大，但依然保持一致性：消息循環(huán)、窗口過程、GDI。雖然當時它的思維模型多少有點古怪，但終歸只有這一套模型。Petzold 把它講清楚了。這就像 Windows 世界里的“F=ma”公式：簡單、強大。你學會它，用它，就能做出想要的成果。

清晰明了就是最好的情況！一個操作系統(tǒng)、一套 API、一種語言、一本書。沒有人爭論托管代碼的替代方案，沒有委員會反復拉扯。只有 Win32 和 Petzold，而且它確實奏效。這更像“物理學”，而不是“化學”——不是那種“在特定元素周期表的一小塊區(qū)域才成立、還得滿足特定壓力、溫度，甚至月亮位置都要剛好”的復雜體系。

接下來發(fā)生的事情，可以說是一堂典型案例：一家擁有頂尖人才和雄厚資源的公司，是如何在三十年時間里，因為優(yōu)化錯了方向，搞出一連串混亂局面的。

換句話說，就是一群聰明人，做出了愚蠢的決定。

面向?qū)ο蟮目駸峄孟螅?992–2000）

Win32 確實存在不少局限，于是微軟做了它一貫會做的事：在開發(fā)者大會上推出“新東西”。而且不是一個，是一堆。

MFC（1992）用 C++ 封裝了 Win32。如果說 Win32 已經(jīng)不夠優(yōu)雅，那 MFC 就像是給 Win32 穿了一件由更多“西裝”拼出來的西裝——復雜到有點滑稽。

隨后出現(xiàn)了 OLE、COM、ActiveX。這些東西本質(zhì)上都不是 GUI 框架，而是組件模型，但它們滲透進了 Windows 開發(fā)的每一個角落，引入了一種認知復雜度。

我至今記得自己在 90 年代末參加過一場會議，整整一個小時都在試圖搞清楚 OLE 文檔、COM 對象和 ActiveX 控件之間的區(qū)別。那一整場，我看著臺上的講者，感覺就像他嘴里掛著一截老鼠尾巴——完全無法理解他在說什么。

微軟當時并沒有提供一個連貫的整體敘事，它只是不斷推出各種技術(shù)“零件”，然后讓開發(fā)者自己去拼出一套體系。

這就是典型的“發(fā)布會主旨演講災難”——微軟優(yōu)化的是高管在臺上如何講得讓人驚艷，而不是開發(fā)者和用戶最終能不能真正成功。

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

在 2003 年的 PDC 大會上，微軟發(fā)布了 Longhorn——可以說，這是它曾經(jīng)向開發(fā)者展示過的最具吸引力的技術(shù)愿景之一。

Longhorn 由三大支柱構(gòu)成：

• WinFS（關(guān)系型文件系統(tǒng)）

• Indigo（統(tǒng)一通信框架

• Avalon，后來演變?yōu)?WPF——一個基于 GPU 加速、矢量化的 UI 子系統(tǒng)，由名為 XAML 的聲明式 XML 語言驅(qū)動。開發(fā)者看到 Avalon 的演示幾乎沸騰，這個方向本身沒有問題。

但用 Jim Allchin 在 2004 年 1 月內(nèi)部備忘錄中的話來說，這個項目“就是一頭豬”。

到了 2004 年 8 月，微軟宣布全面重置開發(fā)：推倒重來，從 Server 2003 的代碼庫重新起步。重置之后，管理層還下達了一條幾乎沒有公開的指令：Windows 中禁止使用任何托管代碼。所有新代碼一律使用 C++。WPF 最終會隨 Vista 發(fā)布，但 Windows 自身的外殼卻不會使用它。

Windows 團隊對 .NET 的怨氣，從此再也沒有消散。

在他們看來，押注一個全新的托管代碼框架，直接導致了公司歷史上最尷尬的一次失敗。這種情緒，演變成了一場持續(xù)了十三年的“體制內(nèi)內(nèi)戰(zhàn)”：Windows 團隊對抗 .NET 團隊。最終的結(jié)果是——WPF 被邊緣化，Silverlight 被放棄，UWP 走向失敗，也造就了今天這個一團亂麻的 Windows GUI 生態(tài)。

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

WPF 在 2006 年末正式發(fā)布。它相當驚艷——XAML、硬件加速渲染、真正可用的數(shù)據(jù)綁定。如果當時微軟把它確立為“唯一答案”，并持續(xù)堅定投入，后面的故事也許會完全不同。

但 2007 年，微軟推出了 Silverlight：一個精簡版的瀏覽器插件，用來對抗 Flash。它跨平臺、優(yōu)雅，同時還是 Windows Phone 的技術(shù)基礎。大約在 2010 年前后，它看起來像是富客戶端的未來。

然而在 MIX 2010 的一次問答環(huán)節(jié)中，一位微軟高管卻表示：Silverlight 并不是一個跨平臺戰(zhàn)略，它的重點在 Windows Phone。HTML5 才是新的方向。而 Silverlight 團隊事先對此毫不知情。那些把核心業(yè)務應用押在 Silverlight 上的開發(fā)者，也是通過這場現(xiàn)場問答才第一次聽說這件事。

Silverlight 并不是死于技術(shù)失敗。技術(shù)本身沒有問題。它死于一次商業(yè)戰(zhàn)略決策，而開發(fā)者是最后才知道的人。

記住這個模式，后面還會反復出現(xiàn)。

Metro 的焦慮與“兩條戰(zhàn)線”的內(nèi)耗（2012）

當時，Apple 已經(jīng)賣出了 2 億部 iPhone，iPad 也在蠶食 PC 市場。微軟的回應是 Windows 8 和 Metro——一個以觸控優(yōu)先為核心的運行時 WinRT，而且刻意不基于 .NET 構(gòu)建。

還記得 Windows 團隊對 .NET 的怨氣嗎？這里就是它的體現(xiàn)：WinRT 是一個原生 C++ 運行時，直接與 WPF、WinForms，以及開發(fā)者過去十年在 .NET 上的投入切割開來。

更混亂的是，當時微軟內(nèi)部其實同時在講兩套完全不同的故事：Windows 團隊在推進 WinRT，而 .NET 團隊還在繼續(xù)推廣 WPF。不同的辦公樓、不同的副總裁、不同的路線圖。

開發(fā)者在 2012 年的 Build 開發(fā)者大會上聽到的是什么？未來屬于 WinRT，同時 HTML + JS 是一等公民，同時 .NET 仍然可用，同時 C++ 強勢回歸，同時你應該寫 Metro 應用，同時你的 WPF 代碼也還能正常運行。

這根本不是什么戰(zhàn)略，而是一場“饑餓游戲”的競技場——六支隊伍同時在爭奪你的注意力。

企業(yè)開發(fā)者很快做出了選擇：他們看了一眼 UWP 的沙盒限制、必須通過應用商店分發(fā)的要求，以及缺失的 Win32 API，然后轉(zhuǎn)身離開。

這個本該帶他們進入“現(xiàn)代應用時代”的框架，實際上卻是為一個從未真正成立的平板應用商店而設計的。

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

Windows 10 帶來了 UWP（Universal Windows Platform）：一次編寫，多端運行，覆蓋 PC、手機、Xbox、HoloLens。表面上看很美好，問題在于：Windows Phone 正在走向消亡，而微軟自家的旗艦應用（Office、Visual Studio，甚至 Windows 自身的外殼）都沒有采用 UWP。

即使沒人公開談論，這個信息已經(jīng)足夠明顯了。

當 UWP 推進受阻之后，官方給出的答案變成了：“看情況”。新應用用 UWP，舊應用繼續(xù)用 WPF，通過 XAML Islands 引入新 API，等待 WinUI 3，同時 UWP 里還有專用的 WinUI 2，再加上 Project Reunion 會解決一切——不過它后來改名叫 Windows App SDK，而且依然不能完全替代 UWP。

同時一群聰明人，做著讓人費解的決策。這更像是技術(shù)版的布朗運動——無規(guī)則、無方向的隨機游走。

Project Reunion / WinUI 3 確實代表了一定程度的進步。但你也可以反過來問一句：這個問題為什么一開始會存在？UWP 的控件之所以與操作系統(tǒng)深度綁定，是因為它們歸 Windows 團隊所有，而不是 .NET 團隊，也不是開發(fā)工具團隊。Project Reunion，本質(zhì)上是一個組織結(jié)構(gòu)問題的“技術(shù)化補丁”。

有開發(fā)者在 2024 年這樣總結(jié)自己的經(jīng)歷：“我一路跟著微軟的各種變化走過來：UAP、UWP、C++/CX 被 C++/WinRT 取代卻沒有配套工具、XAML Islands、XAML Direct、Project Reunion、WinAppSDK 的重啟，還有 WinUI 2.0 和 3.0 之間的混亂切換……”

十四年，十四次轉(zhuǎn)向。這個人，應該先拿一枚勛章，然后再得到一句道歉。

沒有管理員的“動物園”

下面這些，都是今天仍然在 Windows 上實際存在、被使用的 GUI 技術(shù)：

微軟原生框架：

• Win32（1985）—— 仍在，還被廣泛使用。Petzold 的那本書到現(xiàn)在依然適用。

• MFC（1992）—— 基于 Win32 的 C++ 封裝。進入維護期，在企業(yè)軟件和 CAD 領(lǐng)域依然活躍。

• WinForms（2002）—— .NET 對 Win32 的封裝。“可以用，但不推薦?！辈贿^做數(shù)據(jù)錄入界面依然是最快的選擇。

• WPF（2006）—— 基于 XAML、由 DirectX 渲染、已開源。但微軟已經(jīng)不再新增投入。

• WinUI 3 / Windows App SDK（2021）—— 被稱為“現(xiàn)代答案”，但路線仍不明朗。

• 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 技術(shù)，但和微軟沒什么關(guān)系。

• Flutter（Google）—— 使用 Dart，自帶渲染引擎，跨平臺。

• Tauri —— 基于 Rust 的輕量級 Electron 替代方案。

• Qt —— 支持 C++ / Python / JavaScript，嚴肅的跨平臺解決方案。

• React Native for Windows —— 微軟支持的 Facebook 移動框架移植版。

• Avalonia —— 開源的“WPF 精神續(xù)作”。被 JetBrains、GitHub、Unity 等采用——這些開發(fā)者已經(jīng)不再等待微軟。

• Uno Platform —— 把 WinUI API 帶到所有平臺上，在某種意義上比微軟自己更堅持 WinUI。

• Delphi / RAD Studio —— 還活著，還很高效，在垂直行業(yè)軟件中依然占有一席之地。

• Java Swing / JavaFX —— 是的，還在生產(chǎn)環(huán)境中運行。企業(yè)世界從不輕易遺忘。

一共十七種路徑，五種編程語言，三種渲染思路。這已經(jīng)不能叫“平臺”了。也許我沒法給 “boof-a-rama” 下一個精確定義，但我一眼就能認出來。

教訓

幾乎所有失敗的 GUI 嘗試，都可以追溯到三類原因之一：內(nèi)部團隊的權(quán)力博弈（Windows vs .NET）、在開發(fā)者大會上過早押注尚未成熟的平臺（Metro、UWP），或者一次突如其來的商業(yè)戰(zhàn)略轉(zhuǎn)向，把開發(fā)者直接“晾在一邊”（Silverlight）。

這些都不是技術(shù)失敗。很多技術(shù)本身其實是優(yōu)秀的——WPF 是好的，Silverlight 是好的，XAML 也是好的。

真正失敗的，是組織本身。

要么你有一套完整、可信的“成功路徑”理論，覆蓋從采用、投入、維護到遷移的整個生命周期；要么你就只是在做一場開發(fā)者大會的主旨演講。

前者是戰(zhàn)略，后者只是三十年的混亂循環(huán)。

Charles Petzold 曾為了跟上微軟每一次推出的新東西，撰寫了六個版本的《Programming Windows》。最終，第六版停在了 Windows 8 的 WinRT，也就是 2012 年。

這事我不怪他。

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