微軟承認Windows 11仍構建在90年代的Win32之上

當你在 Windows 11 中右鍵點擊一個文件或啟動傳統桌面應用時，其實仍在與誕生于商業互聯網之前的舊代碼打交道：最早可追溯到 Windows 95 時代的 Win32 API 依然是當今最流行桌面操作系統的重要基礎層，而按照微軟高層的說法，這原本并不在公司的長期規劃之內。

在最近由微軟官方 Dev Docs 賬號發布的一段視頻中，微軟 Azure 首席技術官、Sysinternals 套件創始人 Mark Russinovich 直言，Win32 能在 2026 年依舊是“一等公民”級別的 API，是公司歷史上最出乎意料的事情之一，他甚至打趣說，當年人們幻想的是飛行汽車和月球基地，而不是一套誕生于 Windows 95 時代的 API 還能被沿用至今。

這套 30 年歷史的 API 能一路活到今天，在微軟內部屢次“被宣布終結”后仍然堅挺，關鍵在于其之上構建起的龐大應用生態。 Russinovich 將 Win32 形容為 Windows 的“基巖”，無數應用建立在它之上，因此任何徹底替代都將付出巨大的代價。 他以自己在 1996 年創立的 Sysinternals 工具為例表示，如果讓他在當年下注，他會“賭上百萬美元”認為這些工具不會在 2026 年仍然有價值，但現實是：它們不僅活了下來，還比以往更重要。 例如，在 2026 年 3 月的更新中，Sysmon 已被直接整合進 Windows，而誕生于 2000 年代初的 ZoomIt 如今仍是 PowerToys 中最受歡迎的小工具之一。

不過，Win32 的“生命力”并不意味著微軟從未嘗試翻篇，相反，過去二十年里，微軟幾乎搭建出一座“替代框架的墓地”。 在微軟內部，關于“殺死 Win32”的努力幾乎從未停過。 為了解決傳統桌面應用在視覺和交互上的現代化難題，微軟先后推出了 MFC（C++ 封裝）和面向 .NET 開發者的 WinForms，雖然它們本質上仍是對 Win32 的封裝而非替代，卻是微軟在應用層抽象上的早期嘗試。 真正意義上的“替換工程”始于引入 XAML 和硬件加速渲染的 WPF，隨后是短暫押注跨平臺的 Silverlight——這一方案最終在 HTML5 崛起后被淘汰。

最激進的一次替代嘗試出現在 Windows 8 時代：微軟推出了 WinRT，希望開發者構建安全、適配觸控、全屏運行的新式應用，并借此徹底翻新 Windows 應用形態。 但隨著 Windows 8 的界面路線遭遇市場冷遇，公司又在 Windows 10 上轉向 Universal Windows Platform（UWP），強調“跨手機、Xbox 和 PC 的統一應用平臺”。

UWP 過于封閉、沙盒限制嚴格，嚴重束縛了需要深度訪問系統資源的傳統桌面開發者。 Russinovich 在視頻中也承認，微軟歷史上多次試圖“重啟” Windows API 表層，例如 WinRT，但由于厚客戶端與 Win32、瀏覽器端的 HTML 與 JavaScript 之間始終存在割裂，這些嘗試最終都沒有按預期落地。

多次框架“虎頭蛇尾”讓開發者對微軟的原生平臺逐漸失去信任，這是 Windows 桌面應用生態轉向 Web 的重要原因之一。 在此前的一篇報道中，有開發者直言，在微軟的生態里投資一個原生框架開始變成一種“負擔”，沒有人愿意在一個可能隨時被廢棄的平臺上押注多年開發時間。 與此形成諷刺對比的是，正是微軟自己帶頭大舉擁抱 Web：它推出了 WebView2 控件，在桌面應用中嵌入基于 Chromium 的 Microsoft Edge 引擎，隨后整個系統被 Web 應用鋪滿——從 Microsoft Teams、Clipchamp、新版 Outlook、OneDrive，到 Windows 11 小組件面板，甚至最新版本的 Copilot 都以 Web 應用形式存在。

Web 應用在開發和跨平臺維護成本上的優勢顯而易見，但在傳統桌面環境中，這種模式在資源占用上極為低效，每一個應用都嵌入一套完整瀏覽器引擎，幾乎注定帶來內存災難。 基于 Web 的客戶端在“幾乎不做任何事情”的情況下也會占用大量內存，而早期基于 UWP 的原生實現則要輕量得多。 微軟內置的視頻編輯器 Clipchamp 同樣是 Web 應用，除了性能與資源消耗的問題之外，它還被強行綁在 OneDrive 云同步之上，這促使他最終放棄使用這一工具。 將這種體驗與 macOS 對比，更凸顯差距：蘋果用戶可以免費使用高度本地化、緊密集成系統的 iMovie 和 Pages 等應用，而許多忠實 Windows 用戶則被迫依賴類似 Clipchamp 之類需要網絡連接、缺乏深度系統集成、且內存占用高的 Web 方案。

在蘋果推出 600 美元以下高性價比筆記本并取得成功后，微軟開始重新檢視自己的應用戰略，意識到將 Windows 變成“類 Chrome OS”并不符合重度用戶期待，也在實質上損害系統性能。 幾個月前，微軟合伙人架構師 Rudy Huyn 公開確認，他正組建一支專門構建“100% 原生” Windows 11 應用的團隊，公司的重點正加速轉向基于 Windows App SDK 的最新原生 UI 框架 WinUI 3。 WinUI 3 有潛力成為微軟挽回開發者信任的關鍵：它既能提供現代化、符合 Fluent 設計的界面體驗，又允許應用完整、無約束地訪問底層 Win32“基巖”。 微軟最近還發布了 Windows App SDK 2.0 大版本更新，為開發者帶來了語義化版本控制、重構后的 Windows ML 棧，以及更完善的拖放支持，用于將 WebView2 內容無縫嵌入原生 WinUI 3 外殼之中。

在系統自身層面，微軟也開始用 WinUI 3 有節奏地替換最老舊的一批 Win32 界面元素，而不再采用 WinRT 那種“硬重啟”式策略。 Windows 95 時代延續至今的文件資源管理器屬性對話框已被發現將換成支持完整暗黑模式的 WinUI 3 版界面。

經典的“運行”對話框（Win + R）也已經用 WinUI 3 重寫，新版在美觀度上明顯領先，在使用感受上也毫不遜色。 根據測試數據，這一由 .NET AOT 編譯的新運行對話框的中位彈出時間為 94 毫秒，比被替換的舊版更快，這被視為一個信號：現代 WinUI 3 架構完全有能力匹敵甚至超越傳統 Win32 代碼在速度和效率方面的表現。

隨著微軟在更多場景中用原生 WinUI 3 組件替代 WebView2 包裹的 Web 界面，Windows 11 對內存資源的無謂消耗將逐步減少，系統整體也有望回歸輕快、統一和原生優先的方向。 我們或許沒有在 2026 年迎來飛行汽車或月球基地，但在經歷多年框架試驗與路線搖擺之后，Windows 有機會成為一套既尊重自身 Win32 傳統、又真正現代化的桌面操作系統。