Hacker News
The Zig programming language is shifting towards using lower-level Native APIs in ntdll.dll instead of standard Win32 APIs to achieve better performance, reduced binary size, and more direct control over system calls.
AI 生成摘要
Zig 程式語言正逐漸轉向使用 ntdll.dll 中的底層 Native API，而非標準的 Win32 API，藉此獲得更好的效能、縮減二進位檔體積，並實現對系統調用更直接的控制。
這場討論源於 Zig 語言開發團隊決定在 Windows 平台上優先調用低階的 Native API（ntdll.dll），而非微軟官方推薦的 Win32 API（kernel32.dll 等）。這項決策旨在減少標準庫的依賴、提升啟動效能並獲得更精確的系統控制權，但也引發了關於系統穩定性與開發規範的激烈辯論。
針對 Zig 的這項技術選擇，Hacker News 社群呈現出兩極化的反應。支持者認為，雖然微軟官方文件警告開發者不要直接使用 Native API，但實際上許多關鍵的系統行為與效能優化只能透過 ntdll 達成。有留言指出，Win32 API 往往存在過度封裝的問題，例如加載 advapi.dll 會連帶觸發一系列子 DLL 的加載與內部測試，顯著拖慢進程啟動速度。此外，對於追求極致控制的系統級語言來說，直接與核心對話能避免 Win32 子系統中某些不透明的相容性邏輯干擾。
然而，反對聲音則集中在 ABI 穩定性與長期維護成本上。多位資深開發者指出，Windows 與 Linux 的哲學截然不同：Linux 保證系統調用（syscall）介面的穩定，而 Windows 則保證 Win32 API 的穩定。若繞過 Win32 直接調用 Native API，本質上是在挑戰微軟隨時可能更動的內部實作。有人以 Go 語言在 macOS 上的教訓為例，當時 Go 團隊試圖繞過 libc 直接進行系統調用，最終因蘋果頻繁變更核心介面而被迫回歸標準庫。批評者擔心，Zig 的做法會導致編譯出的程式在未來的 Windows 版本中失效，且這種「技術債」最終會轉嫁給應用層開發者，迫使他們必須不斷更新編譯器版本以修復底層相容性問題。
另一個引起廣泛討論的爭議點是防毒軟體（AV）的誤報。由於惡意軟體經常使用 Native API 來規避監控，Zig 編譯出的二進位檔極易被啟動啟發式掃描的防毒軟體隔離。雖然 Zig 團隊認為這是防毒軟體廠商應解決的問題，但社群普遍認為這對終端用戶與開發者而言是巨大的負擔，即便使用昂貴的 EV 憑證簽章也難以完全根除。此外，也有專家提到「系統版本欺騙」的問題，若應用程式未正確配置 Manifest 卻又透過 Native API 獲取真實版本號，可能導致 Win32 子系統進入不一致的相容模式，進而引發難以調試的運行時異常。
儘管存在風險，部分留言者也緩頰表示，ntdll 中許多被記錄在 MSDN 上的函數實際上已相當穩定。微軟為了維持自身系統組件的運作，不太可能輕易破壞這些基礎設施。這場爭論反映了系統程式語言在「追求極致效能」與「遵循作業系統設計規範」之間的永恆拉鋸。