背景

這篇文章源於微軟資深工程師 Raymond Chen 的技術部落格，探討開發者如何告知 Windows 系統正在寫入「二進位檔案」而非「文字檔案」。文章澄清了一個核心觀念：Windows 核心 API（如 WriteFile）並不區分檔案類型，對作業系統而言，所有檔案皆為位元組流，任何關於換行符號（CRLF）的轉換或編碼處理，實際上都是由高階語言的執行環境（Runtime Library）所負責。

社群觀點

Hacker News 的討論圍繞著「作業系統與程式語言執行環境的邊界」展開。許多開發者指出，這種對文字與二進位模式的區分，本質上是為了相容性而產生的歷史產物。在 DOS 時代，為了讓 Unix 程式能順利移植，C 語言函式庫引入了自動將 \n 轉換為 \r\n 的機制。部分留言者認為，這種設計雖然方便了跨平台開發，卻也造成了長期的混淆，讓許多開發者誤以為換行符號的轉換是作業系統底層的功能。

討論中出現了關於 Windows 與 Unix 哲學差異的辯論。有觀點認為，Unix 將 C 語言執行環境與作業系統緊密結合，使得 libc 幾乎等同於系統介面；然而在 Windows 上，真正的系統介面是 Win32 API，它與 C 語言標準函式庫（CRT）是分離的。這引發了關於「什麼才算作業系統一部分」的爭論。支持 Windows 設計的一方指出，Windows 支援多種語言（如 Delphi、Go、Assembly），這些語言擁有各自的執行環境，不應強迫所有程式都依賴 C 語言的行為模式。反觀 Unix 系統，雖然核心同樣處理位元組，但其生態系高度依賴 C 語言標準，導致開發者往往分不清核心系統呼叫與函式庫包裝層的差異。

此外，社群也深入探討了換行符號的演進史。有開發者補充，\r\n 的組合源自電傳打字機與早期印表機的物理限制，需要分別執行「移動噴頭回到行首」與「捲動紙張」兩個動作。Unix 選擇簡化為單一字元是為了處理效率，而 Windows 繼承自 CP/M 與 DOS 的慣例則是為了確保與當時硬體設備的直接相容性。儘管現代開發環境已趨於統一，但這種底層差異依然在跨平台開發中造成不少困擾，例如 Git 處理換行符號的機制，本質上就是在解決這篇文章所討論的層級問題。

最後，討論也觸及了 Windows 近年來的轉變。隨著 Windows 10 引入通用 C 執行環境（UCRT），C 函式庫終於成為作業系統正式分發的一部分，這在某種程度上模糊了 Raymond Chen 所強調的界線。然而，資深開發者仍強調理解底層 Win32 API 的重要性，因為這能幫助開發者在處理非文字數據或高效能 I/O 時，避免被執行環境不必要的自動轉換所干擾。

延伸閱讀

• The Universal CRT：微軟關於通用 C 執行環境的官方文件。
• The EOL Story：關於網際網路標準中換行符號歷史的 RFC 背景資料。
• SetConsoleMode：Win32 API 中處理主控台輸入輸出模式的對應函式。