編譯丨千山
相比Python、Java這樣的主流語言，Rust可能還比較小眾，但近兩年其影響力和所受關注度卻在與日俱增。
- 在 StackOverflow 開發者調查問卷中，Rust連續八年蟬聯最受歡迎程式語言榜首。
- 在新近出爐的Tiobe九月程式語言排行榜中，Rust排名更是上升到第17位。
- 不久前Jetbrains 官宣發布了獨立的Rust IDE :RustRover（詳見之前的報道《棄用開源插件！JetBrains決定對Rust出手！》）。
可以說，Rust正在進入更加成熟與擴大應用規模的階段。在Rust的一眾支持者中，微軟可謂相當高調。
今年4月，在BlueHat IL 2023會議上，Windows作業系統安全總監David dwizzle Weston宣布 Rust 正式進入作業系統內核。如今，微軟在擁抱Rust的道路上再次放出大招。
重寫內核還不夠，Windows已經開始有了適配Rust驅動的打算！昨天，微軟突然在Github上開放一個重磅項目——windows-drivers-rs，它支持開發人員使用Rust為Windows開發驅動程序。這是作業系統內存安全編程的關鍵一步。
為此，Azure的CTO Mark Russinovich特意在X（推特）上發布了這個連結，並評論道:「致力於在Rust中實現Windows驅動程序的開發。」
1、打破閉源，微軟選擇Rust的背後
微軟對於Rust的看好可以追溯到多年以前。2019年7月，微軟研究院發布了一份聲明，希望「在漏洞發生之前消除一整類漏洞」，為內存安全語言提供了理由，並指出「滿足這些要求的最有前途的新系統程式語言之一是最初由Mozilla發明的Rust程式語言」。
Rust語言的特性或者說其設計目標之一就是提供內存安全保證，避免出現內存泄漏、緩衝區溢出等問題。這一點是微軟看重它的重要原因之一，此外，這門語言的並發性能也極為出色，它提供了輕量級的線程和異步編程模型，可以充分利用多核處理器的性能。
從現有公開資料來看，Windows的Rust改造始於2020年，由DWriteCore開始。DWriteCore 是 Windows 的DWrite引擎的Windows應用程式SDK實現，用於文本分析、布局和渲染。DWriteCore 現在由大約152000行Rust代碼和大約96000行C++代碼組成。
2、拋棄C++，用Rust開發Windows
「說到語言，現在是時候停止用 C/C++ 啟動任何新項目了，並在那些需要使用 non-GC 語言的場景中使用 Rust。為了安全性和可靠性，業界應該宣布棄用這些語言。」
這是去年Mark Russinovich在其社交帳號上公開發布的動態。作為Azure CTO，他的言論一石激起千層浪。
隨後C++之父 Bjarne Stroustrup的隔空回應又讓這場辯論再添一絲火藥味。「新的語言通常需要多年的時間和重大的努力，才能在其廣泛的應用領域中與成熟的語言相媲美。發燒友們很少看到這一點，他們的評論往往是相當片面的。」
且不論這場battle結果如何，微軟官方雖然沒有明確表態，但在擁抱Rust的力度上卻是在穩步推進的。
由於各種技術和歷史原因，Windows主要是用C和C++編寫的。「大多數用戶模式代碼現在都是用C++編寫的，但大多數內核代碼仍然是用C編寫的。」
微軟資深軟體工程師Raymond Chen在2018年表示，儘管Windows 11從那時起就出現了，但在開發新版本時，作業系統並沒有重寫。硬體製造商使用Windows驅動工具包使他們的設備能夠在Windows中工作，它仍然是一個C/ C++工具包。
而最新推出的名為windows-drivers-rs的項目帶來了全新的可能性。
根據新的基於Rust的驅動工具包的發布說明，其目的是同時支持 WDM（Windows 驅動程序模型）和 WDF（Windows 驅動程序框架）。WDM 驅動程序級別較低，與作業系統緊密綁定，而 WDF 驅動程序通過框架庫與系統交互。
該存儲庫包含Rust crate，允許開發人員使用WDM和WDF驅動程序開發模型創建Windows驅動程序。當前版本的存儲庫包含以下crate、庫和宏集：wdk-build、wdk-sys、wdk、wdk-panic、wdk-alloc、wdk-macros。
3、處於早期，Rust重構Windows或成定局
發布說明還提到，該項目仍處於早期開發階段，不建議用於商業用途。微軟鼓勵實驗和反饋，並指出開發人員可以在GitHub討論論壇上獲得反饋。
之所以稱為「早期」，是因為還面臨諸多挑戰，比如，如何處理異常。「對於Windows內核(以及一般的作業系統)來說，結構化異常處理是Windows開發的一個組成部分，也是讓Rust成為Windows內核開發現實的真正障礙，」一名開發人員如是說。
Rust的錯誤處理機制中，錯誤分為兩類：可恢復的和不可恢復的。Rust更喜歡使用Result變量報告可恢復的錯誤，並在出現不可恢復的錯誤時使用panic failure退出。但這種故障處理在內核代碼中是不可取的，因為它們會導致系統崩潰。
開發人員Johnny Shaw引用Linux Torvalds的話說，在Linux內核（也採用Rust）的上下文中，「因為內核代碼不同於隨機的用戶空間系統工具。內存不足絕對不能導致中止。它只需要導致錯誤返回。」Torvalds認為這是一個「根本問題」。
微軟新存儲庫的早期代碼包括如下注釋：
// FIXME: Should this trigger Bugcheck via KeBugCheckEx?
這個問題說明，將Rust引入底層Windows代碼不僅僅是為WDK api添加Rust語言綁定的問題。其牽涉的細節往往牽一髮而動全身。
不過目前來看，內存安全問題在Windows的安全性和穩定性問題中占很大比重，轉向Rust是一個可能的解決方案。而且從積極的意義上來說，隨著內存安全編程的重要性愈發受到行業認可，業界對於Rust的探索會愈發深入，微軟則會繼續在保護原生代碼的前提下探究在Rust中重構Windows的可能，進而為Rust的工程化實踐添磚加瓦。