這些年，如果你還在認(rèn)真考慮“要不要做一個(gè)原生 Windows 應(yīng)用”，大概率會(huì)很快陷入一種說不清的困惑。

一方面，這個(gè)平臺(tái)看起來從不缺“新東西”：從 Win32、MFC，到 .NET、WPF，再到后來的 UWP、WinUI 3，技術(shù)棧不斷演進(jìn)，概念也越來越現(xiàn)代；另一方面，真正動(dòng)手做點(diǎn)事情時(shí)，卻總會(huì)遇到一種強(qiáng)烈的割裂感——新框架不完整，老能力又離不開，開發(fā)體驗(yàn)在“過時(shí)”和“半成品”之間反復(fù)橫跳。

更現(xiàn)實(shí)的是，就連微軟自己，也在用行動(dòng)投票：從 Visual Studio Code 到新版 Microsoft Outlook，再到系統(tǒng)里越來越多的界面，本質(zhì)上都在向 Web 技術(shù)靠攏。原生開發(fā)，反而成了一種“理論上重要，但實(shí)踐中逐漸邊緣化”的選項(xiàng)。

這也就帶來一個(gè)耐人尋味的問題：當(dāng)一個(gè)平臺(tái)連自己的核心應(yīng)用都不再堅(jiān)定使用“原生方案”時(shí)，開發(fā)者為什么還要堅(jiān)持？

在這篇文章里，一位親自踩過坑的開發(fā)者嘗試寫一個(gè)再簡(jiǎn)單不過的小工具，但正是在這個(gè)過程中，他把 Windows 原生開發(fā)這些年的斷層、重復(fù)和妥協(xié)，一層層掀開來看。

原文鏈接：https://domenic.me/windows-native-dev

作者 | Domenic Denicola 責(zé)編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

我是一名 Windows 忠實(shí)用戶。《Beginning Visual C++ 6》是我最早接觸的編程書籍之一。這本書的關(guān)鍵在于它附帶了一個(gè) Visual C++ 試用版，我十歲的時(shí)候就能在家里的電腦上自己裝起來。我還記得 .NET 1.0 發(fā)布時(shí)，我們正在度假，當(dāng)時(shí)我一邊啃一本 C# 大全，一邊盤算著把自己寫的 Neopets 作弊程序從 MFC 重寫成 Windows Forms。甚至我大學(xué)畢業(yè)后的第一份工作，也是在一家做 .NET 的公司，只不過我當(dāng)時(shí)負(fù)責(zé)的是前端開發(fā)。

這些年來，雖然我一直在關(guān)注著 Windows 開發(fā)生態(tài)系統(tǒng)，但職業(yè)生涯里其實(shí)從來沒真正寫過原生的 Windows 應(yīng)用。（嚴(yán)格來說，Chromium 算是原生應(yīng)用，但更像是一個(gè)自成體系的操作系統(tǒng)。）至于個(gè)人項(xiàng)目，Web 一直是更合適的選擇。不過，被童年記憶勾起的一點(diǎn)情懷驅(qū)動(dòng)，我想著寫一個(gè)有趣的小型 Windows 工具，當(dāng)作“退休項(xiàng)目”也不錯(cuò)。

結(jié)果呢……我可以負(fù)責(zé)任地說，Windows 原生開發(fā)這個(gè)生態(tài)現(xiàn)在就是一團(tuán)亂。我完全理解為什么如今幾乎沒人再寫原生 Windows 應(yīng)用，大家都轉(zhuǎn)向了 Electron。

我做了個(gè)什么？

我寫的這個(gè)小工具叫 Display Blackout（https://github.com/domenic/display-blackout），主要是解決我自己的一個(gè)小需求：

我用的是三屏顯示器，在打游戲的時(shí)候，希望把左右兩塊屏幕“黑掉”。如果直接關(guān)掉顯示器，Windows 往往會(huì)“抽風(fēng)”好幾秒，還會(huì)把當(dāng)前所有窗口的位置打亂。但如果是 OLED 屏，只要蓋一層純黑窗口，就等于把像素全關(guān)掉，效果其實(shí)是一樣的。

需要說明的是，這并非我的原創(chuàng)想法。我一開始用的是一個(gè)叫 AutoHotkey 的腳本（https://github.com/Quorthon13/OLED-Sleeper/blob/eb6eb3e1432c9510899d1aedc345876245adbc72/src/OLED-Sleeper.ahk），寫這篇文章時(shí)才發(fā)現(xiàn)它已經(jīng)發(fā)展成一個(gè)完整的 Windows 應(yīng)用了。類似的工具在 Microsoft Store 上也能找到。不過，我還是想自己做一個(gè)界面更現(xiàn)代一點(diǎn)的小工具——而且本來也不是為了做產(chǎn)品，主要是為了學(xué)習(xí)。

從我們的角度來看，這個(gè)應(yīng)用有意思的地方在于，它需要具備這些能力：

• 列舉當(dāng)前機(jī)器上的所有顯示器及其邊界

• 創(chuàng)建無邊框、無標(biāo)題欄、不會(huì)搶焦點(diǎn)的純黑窗口

• 攔截全局快捷鍵

• （可選）開機(jī)自啟動(dòng)

• 保存一些持久化設(shè)置

• 在系統(tǒng)托盤里放一個(gè)圖標(biāo)，并帶有簡(jiǎn)單菜單

先把這些需求記住，后面會(huì)用到。

看看我做的這個(gè)漂亮的界面。你肯定會(huì)同意，它比同類軟件都好。

Windows 編程簡(jiǎn)史

一開始，Win32 API 是用 C 寫的。不幸的是，這套 API 到今天依然非常重要，包括我這個(gè)小工具也離不開它。

隨著時(shí)間推移，在此基礎(chǔ)上出現(xiàn)了一系列抽象層。.NET 之前最主要的是 MFC（一個(gè) C++ 庫），它利用當(dāng)時(shí)算比較“現(xiàn)代”的語言特性，比如類和模板，在原始的 C 函數(shù)之上加了一點(diǎn)面向?qū)ο蟮奶匦浴?/p>

真正的“抽象加速列車”，是在 .NET 出現(xiàn)之后才啟動(dòng)的。

.NET 有很多層意義，但對(duì)我們來說最關(guān)鍵的是：它引入了一門新語言 C#，以類似 Java 的方式運(yùn)行在一個(gè)新的虛擬機(jī)上（JIT 字節(jié)碼）。這帶來了自動(dòng)內(nèi)存管理（也就是內(nèi)存安全），也讓微軟的整個(gè)開發(fā)生態(tài)有了更現(xiàn)代的基礎(chǔ)。

同時(shí)，.NET 還提供了一整套新的 Windows API。UI 方面，.NET 1.0（2002 年）帶來了 Windows Forms，本質(zhì)上還是對(duì) Win32 窗口和控件 API 的一層封裝，和 MFC 很像。

到了 .NET 3.0（2006 年），微軟推出了 WPF。這時(shí)候不再只是用 C# 對(duì)象來創(chuàng)建控件，而是引入了一種獨(dú)立的標(biāo)記語言 XAML，有點(diǎn)像 HTML + JavaScript 的關(guān)系。與此同時(shí)，這也是他們第一次徹底重寫控件——用 GPU 渲染，而不是簡(jiǎn)單封裝系統(tǒng)自帶的 Win32 控件。當(dāng)時(shí)看起來，這像是一個(gè)全新的起點(diǎn)，也像是未來 Windows 應(yīng)用的長(zhǎng)期基礎(chǔ)。

下一次大的轉(zhuǎn)折點(diǎn)，是 Windows 8（2012 年）發(fā)布時(shí)引入的 WinRT。它和 .NET 類似，試圖為開發(fā) Windows 應(yīng)用提供一整套新的 API。如果開發(fā)者完全遵循 WinRT 的規(guī)則，那么應(yīng)用就能符合“現(xiàn)代應(yīng)用”的標(biāo)準(zhǔn)：沙箱化（類似 Android 和 iOS），并且可以同時(shí)部署在桌面、平板和手機(jī)上。UI 仍然基于 XAML，但相比 WPF 做了不少調(diào)整，以適應(yīng)跨設(shè)備的限制環(huán)境。

這個(gè)策略在 Windows 10（2015 年）里被“重做”了一次，變成了 UWP。它放松了一些沙箱限制，讓應(yīng)用能覆蓋桌面 / 手機(jī) / Xbox / HoloLens，同時(shí)能力比 WinRT 更強(qiáng)，但仍然達(dá)不到 WPF 那種完整 .NET 應(yīng)用的自由度。與此同時(shí)，WinRT / UWP 還帶來一個(gè)問題：某些系統(tǒng)級(jí)功能（比如推送通知、動(dòng)態(tài)磁貼、Microsoft Store 分發(fā)）只開放給這些框架。這導(dǎo)致像 Chrome 或 Microsoft Office 這樣的應(yīng)用，不得不在舊核心外面套一層 WinRT/UWP 外殼，通過 IPC 等方式通信，架構(gòu)變得很別扭。

到了 Windows 11（2021 年），微軟基本放棄了把所有人遷移到“更現(xiàn)代、更沙箱化平臺(tái)”的嘗試。Windows App SDK 把原本只屬于 WinRT/UWP 的那些能力開放給所有 Windows 應(yīng)用——無論是標(biāo)準(zhǔn) C++（也不再需要 C++/CLI），還是 .NET。這個(gè) SDK 里還包含了 WinUI 3，又一套基于 XAML、完全重寫的 UI 控件庫。

所以你看懂了嗎？光是 UI 框架這條線，就已經(jīng)走過了：

Win32 C APIs → MFC → WinForms → WPF → WinRT XAML → UWP XAML → WinUI 3

路線分叉

既然這是個(gè)學(xué)習(xí)項(xiàng)目，我一開始就決定用“最新、最官方”的技術(shù)棧，也就是基于 Windows App SDK 的 WinUI 3 應(yīng)用。

但具體怎么選，又是一個(gè)三選一的問題：

• C++

• C#/XAML + “framework-dependent deployment”（依賴系統(tǒng)運(yùn)行時(shí)）

• C#/XAML + .NET AOT

這是個(gè)很痛苦的選擇。

用 C++ 可以做出很輕量的應(yīng)用，運(yùn)行時(shí)只依賴 Windows App SDK，自帶和 Win32 API 的無縫互操作。但在 2026 年，用一個(gè)內(nèi)存不安全的語言從零開始寫新項(xiàng)目，多少有點(diǎn)“逆時(shí)代”。

理想情況是：直接用系統(tǒng)自帶的 .NET，只分發(fā) C# 字節(jié)碼，就像 Web 應(yīng)用共享瀏覽器一樣。這就是所謂的 “framework-dependent deployment”。但問題在于——我完全無法理解的一個(gè)決定是：即便是最新的 Windows 11，也只預(yù)裝了 .NET 4.8.1，而當(dāng)前版本已經(jīng)是 .NET 10。結(jié)果就是，只要有一個(gè)應(yīng)用需要新版本 .NET，系統(tǒng)就會(huì)彈窗提示用戶去下載運(yùn)行時(shí)。這體驗(yàn)顯然很糟糕。

于是只剩下 .NET AOT 這一條路：把整個(gè) .NET 運(yùn)行時(shí)——包括虛擬機(jī)、垃圾回收器、標(biāo)準(zhǔn)庫——全部編譯進(jìn)一個(gè)可執(zhí)行文件。雖然編譯器會(huì)盡量裁剪沒用的代碼，但最后一個(gè)“只是把屏幕變黑”的小工具，體積也有 9MB。

（“那 Rust 呢？”你可能會(huì)問。微軟周邊社區(qū)曾嘗試維護(hù) Windows App SDK 的 Rust 綁定，但后來放棄了。）

此外，分發(fā)方式也一樣讓人頭疼。雖然 Windows 支持傳統(tǒng)的 setup.exe 安裝器（無論手寫還是第三方工具生成），但微軟推薦的“現(xiàn)代方案”是 MSIX——一個(gè)帶容器化安裝/卸載能力的包格式。

問題是，MSIX 非常依賴代碼簽名證書，而這個(gè)東西對(duì)非美國開發(fā)者來說，每年大概要 200–300 美元。沒有簽名的話，側(cè)載體驗(yàn)極其糟糕：需要在管理員 PowerShell 里輸入一長(zhǎng)串晦澀命令。

你可能會(huì)想，那直接上 Microsoft Store 不就好了？不好意思，我試了——被拒了，理由是“沒有提供獨(dú)特且持久的價(jià)值”。

最讓人難受的是，這一切其實(shí)都不是技術(shù)上做不到，而是完全可以更簡(jiǎn)單：

• .NET 本可以通過 Windows Update 分發(fā)，讓系統(tǒng)始終保持最新版本，這樣 framework-dependent deployment 就能成立
  

• 至少也可以提供一個(gè) MSIX 版的 .NET，讓其他 MSIX 應(yīng)用聲明依賴

• 未簽名 MSIX 本可以像 EXE 一樣使用基于用戶反饋的信譽(yù)系統(tǒng)

• Windows 的代碼簽名證書，本可以像 Apple 生態(tài)那樣只要 100 美元/年，而不是 200+

但現(xiàn)實(shí)是——就像現(xiàn)在的 Windows 開發(fā)體驗(yàn)一樣，這些東西都只做到一半，處處透著一種“差點(diǎn)意思”。

被“遺落”的能力

事實(shí)證明，每隔幾年就把操作系統(tǒng)和 UI API 重造一遍，是一件非常耗費(fèi)精力的事情。再加上中途不斷嘗試做沙箱化、限制那些“過于強(qiáng)大”的能力，結(jié)果就是：每一層新框架都會(huì)留下缺口——一些在舊框架里能做的事情，在新框架里反而做不了了。

這其實(shí)不是什么新問題。早在 MFC 時(shí)代，你就經(jīng)常不得不回退去直接調(diào)用 Win32 API；而 .NET 從 1.0 開始就有 P/Invoke 這種“逃生通道”。所以，從某種角度看，既然微軟現(xiàn)在也不再強(qiáng)制你必須只用最新框架才能獲得新能力，那么偶爾往下層調(diào)用也不算世界末日。

但問題在于，這很讓人挫?。喝绻话氲拇a都只是用來做 interop、去調(diào)用那些老舊的 API，那用微軟最新最好的技術(shù)還有什么意義？如果最后還是要去封裝一堆 C API，那用 C# 編程又有什么意義？

讓我們重新審視一下我的應(yīng)用程序需要完成的任務(wù)列表，對(duì)照一下 Windows App SDK 實(shí)際能做什么：

• 枚舉顯示器及其邊界：可以做到，但你得用 for 循環(huán)，不能用 foreach。而如果想監(jiān)聽顯示器變化，就必須用 P/Invoke，因?yàn)楝F(xiàn)代 API 根本不好用。
  

• 創(chuàng)建無邊框、無標(biāo)題欄、不會(huì)搶焦點(diǎn)的黑色窗口：大部分可以實(shí)現(xiàn)，但“不會(huì)搶焦點(diǎn)”這一點(diǎn)，還是得靠 P/Invoke。
  

• 攔截全局快捷鍵：不行，必須 P/Invoke。

• 開機(jī)自啟動(dòng)（可選）：這個(gè)可以，而且還提供了一個(gè)和系統(tǒng)設(shè)置集成、默認(rèn)關(guān)閉的現(xiàn)代 API，算是做得不錯(cuò)。
  

• 持久化存儲(chǔ)設(shè)置：可以做到。

• 顯示帶有少量菜單項(xiàng)的托盤圖標(biāo)：完全沒有實(shí)現(xiàn)。托盤圖標(biāo)本身要靠 P/Invoke；更麻煩的是，托盤菜單并沒有統(tǒng)一標(biāo)準(zhǔn)——你選不同的第三方封裝庫，最后出來的右鍵菜單風(fēng)格都不一樣。

Windows IME 系統(tǒng)組件采用現(xiàn)代磨砂玻璃風(fēng)格，與一些其他系統(tǒng)組件相匹配，但我找不到任何應(yīng)用程序（包括 Microsoft 應(yīng)用程序）與之匹配。

總結(jié)下來就是：看起來是“現(xiàn)代框架”，但很多關(guān)鍵能力不是缺失，就是半殘，最后還是繞回老 API。

但這些還只是“顯眼的問題”。甚至連一個(gè)很基礎(chǔ)的功能——根據(jù)內(nèi)容自動(dòng)調(diào)整窗口大小——也在從 WPF 走到 WinUI 3 的過程中，不知什么時(shí)候被弄丟了。

更麻煩的是，既然你經(jīng)常需要回退調(diào)用 Win32 C API，那么 interop 本身也在“換代”，事情就更復(fù)雜了。

現(xiàn)在所謂的“現(xiàn)代方案”是一個(gè)叫 CsWin32 的東西，目標(biāo)是降低 P/Invoke 的痛苦。但它連結(jié)構(gòu)體里的字符串都沒法正確封裝。在我看來，這就是那種長(zhǎng)期停留在 1.0 之前、資金和投入都不足、更新記錄也毫無亮點(diǎn)的項(xiàng)目——大概率再過幾年就會(huì)被放棄。

而且，CsWin32 的問題不只是實(shí)現(xiàn)不完整，有些甚至源于 C# 語言本身的缺陷。官方文檔里有一段讓人哭笑不得的說明：

Win32 中有些參數(shù)是 [optional, out] 或 [optional, in, out]。C# 沒有符合習(xí)慣的方式來表達(dá)這種概念，因此對(duì)于包含這類參數(shù)的方法，CsWin32 會(huì)生成兩個(gè)版本：一個(gè)包含所有 ref/out 參數(shù)，另一個(gè)則全部省略。

也就是說，C# 連 Win32 API 里一個(gè)非?；A(chǔ)的參數(shù)類型都表達(dá)不了？這不過是現(xiàn)有兩種參數(shù)語義的組合而已。

按理說，既然微軟完全掌控 C#，那它應(yīng)該是一個(gè)圍繞 Windows API 精心打磨、協(xié)同演進(jìn)的語言。但現(xiàn)實(shí)顯然不是這樣。

實(shí)際上，不只是調(diào)用老的 Win32 API 時(shí) C# 顯得力不從心，就連面對(duì)自身平臺(tái)需求，它也沒跟上。

2006 年 WPF 剛推出時(shí)，大力強(qiáng)調(diào)“雙向數(shù)據(jù)綁定”，大家很快就發(fā)現(xiàn)：為了讓一個(gè)類能綁定到 UI，需要寫大量樣板代碼，根本不可持續(xù)。基本上，每個(gè)屬性都要寫成 getter/setter，對(duì) setter 做“值未變化則跳過”的判斷，還要手動(dòng)觸發(fā)事件。（而在 C# 里，觸發(fā)事件本身就很啰嗦。）后來大家嘗試過各種“補(bǔ)丁式”的方案，比如基類、代碼生成器等等。但真正的解決辦法，其實(shí)應(yīng)該是語言層面的支持——就像 JavaScript 通過 decorators 和 proxy 做到的那樣。

結(jié)果呢？

當(dāng)我這次自己動(dòng)手寫應(yīng)用時(shí)，驚訝地發(fā)現(xiàn)：WPF 發(fā)布 20 年之后，這些樣板代碼幾乎沒怎么變。（唯一的改進(jìn)，是 C# 允許在觸發(fā)事件時(shí)省略屬性名。）

這不禁讓人想問：這二十年來，C# 語言團(tuán)隊(duì)到底在忙什么？為什么“原生可觀察類”這種需求從來沒被優(yōu)先解決？

總結(jié)

說實(shí)話，我感覺微軟對(duì)原生 Windows 應(yīng)用開發(fā)這件事根本就不重視。

相關(guān)的 issue 追蹤里，到處都是開發(fā)者遇到各種痛苦的 bug 和功能缺失，但微軟工程師的回應(yīng)寥寥無幾。大多數(shù)的 Windows App SDK 更新日志也都是在新增機(jī)器學(xué)習(xí) API。

而更諷刺的是，從 Visual Studio Code、Outlook，到甚至 Windows 開始菜單本身，很多微軟自家的應(yīng)用，都是用 Web 技術(shù)寫的。

這或許也是為什么社區(qū)里很大一部分人選擇“另起爐灶”，轉(zhuǎn)向第三方 UI 框架，比如 Avalonia 和 Uno Platform。從它們的官網(wǎng)和 GitHub 倉庫來看，這些項(xiàng)目維護(hù)得更好，也更像是由一群真正熱愛 WPF、但希望 WinUI 能更強(qiáng)大的人在推動(dòng)。同時(shí)，它們也擁抱跨平臺(tái)，這在不少場(chǎng)景下確實(shí)很重要。

但說到這里，很多人會(huì)好奇地直接問一句：那為什么不干脆用 Electron 呢？

說真的，C# 和 XAML 并沒有比 TypeScript / React / CSS 強(qiáng)到哪里去。就像我上文列出的那份需求列表所展示的，只要稍微超出基礎(chǔ)功能，你最終還是得用到 Win32 互操作。如果你使用的是像 Tauri 這樣的框架，甚至都不用打包整個(gè) Chromium 二進(jìn)制文件，其實(shí)只用系統(tǒng)自帶的 WebView 就夠了。然而，這個(gè)系統(tǒng)自帶的 WebView 每 4 周（甚至很快變成 2 周）就更新一次，而系統(tǒng)自帶的 .NET 卻永遠(yuǎn)停在 4.8.1 版本。

當(dāng)然，微軟也不是完全沒機(jī)會(huì)扭轉(zhuǎn)局面。

Windows App SDK 至少比當(dāng)年繞進(jìn) WinRT / UWP 那一大圈要更靠譜一些。前面提到的打包和分發(fā)問題，其實(shí)也有不少“低垂的果實(shí)”可以改進(jìn)。另外，他們最近也提到要提升 Windows 的整體質(zhì)量，并且計(jì)劃在系統(tǒng)內(nèi)部更多使用 WinUI 3——理論上，這可能會(huì)反過來推動(dòng) WinUI 本身的完善。

不過，我并不抱太大期待。從目前的情況看，大多數(shù)開發(fā)者也持相同的態(tài)度。

Hacker News 上的人總愛感嘆“原生應(yīng)用的消亡”，但考慮到 Windows 應(yīng)用平臺(tái)如今的混亂程度，我寧可每天用 Web 技術(shù)棧，再用 Electron 或 Tauri 去橋接必要的 Win32 能力。

110 萬美金懸賞！

AMD 2026 線上黑客松大賽來襲

從 MXFP4 MoE 算子爆改，到真實(shí)千倍并發(fā)下的吞吐量極限拉扯

不看資歷，只看絕對(duì)速度

挑戰(zhàn)DeepSeek?R1/KimiK2.5極致并發(fā)

入圍即能拿 1 萬美金