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

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

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

他直言，很多技術(shù)的興衰，并非源自技術(shù)本身，而是內(nèi)部團(tuán)隊(duì)的權(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 責(zé)編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這就是典型的“發(fā)布會主旨演講災(zāi)難”——微軟優(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)部備忘錄中的話來說，這個項(xiàng)目“就是一頭豬”。

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

Windows 團(tuán)隊(duì)對 .NET 的怨氣，從此再也沒有消散。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有開發(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)向。這個人，應(yīng)該先拿一枚勛章，然后再得到一句道歉。

沒有管理員的“動物園”

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

微軟原生框架：

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

• MFC（1992）—— 基于 Win32 的 C++ 封裝。進(jìn)入維護(hù)期，在企業(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 團(tuán)隊(duì)當(dāng)前押注的方向。

微軟的 Web 混合方案：

• Blazor Hybrid —— 在原生 WebView 中運(yùn)行 .NET 的 Razor 組件。

• WebView2 —— 在 Win32 / WinForms / WPF 應(yīng)用中嵌入 Chromium。

第三方方案：

• Electron —— Chromium + Node.js。VS Code、Slack、Discord 都在用。如今 Windows 上部署最廣泛的桌面 GUI 技術(shù)，但和微軟沒什么關(guān)系。

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

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

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

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

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

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

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

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

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

教訓(xùn)

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

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

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

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

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

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

這事我不怪他。

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