我是一位喜歡鑽研舊事物的老程式設計師。

你可能會覺得標題有點奇怪，請先暫且保留你的想法，聽我說完。我深信在科技與生活中，由大型自上而下的標準化組織所產生的共識，通常會失敗。網際網路就是一個例子，當科學家提交 RFC 文件並反覆修訂，最終成為事實上的網際網路協定。

關鍵字是「反覆修訂」。大多數標準組織試圖涵蓋許多使用案例，主要是為了其成員的利益，這導致標準臃腫、效率低落且多半未被廣泛使用。相較之下，較靈活的競爭者則被採用、反覆改進並擴展。在網路協定的案例中，OSI 模型如今基本上只存在於網路訓練、認證與課程中；在現實世界中，網際網路是 TCP/IP，TCP/IP 運行於電腦、手機及其他裝置上。

成功的標準是由務實主義驅動的。其中一個例子是 POSIX 標準。該標準源自於統一 UNIX 變體與克隆系統的 API 需求。大多數現代作業系統皆實作此標準，從知名的 Linux 與 Darwin（即 Apple macOS）核心，到業餘作業系統如 Redox 與 Managarm，都將 POSIX 作為其使用者空間 API。你可能會問，為什麼我沒提到 Windows？我稍後會談到。

他們實作 POSIX 是因為它提供了豐富的生態系統。所有 GNU 工具鏈，如 GCC，都能在符合 POSIX 的作業系統上運行。如果你打造一個作業系統核心，並採用 POSIX 作為使用者空間 API 以及良好的終端機，便能輕鬆存取廣泛的軟體選擇。

Apple 在打造 Darwin（macOS 的核心，前身為 NeXTStep）時採用了這條路。NeXT 將 Mach 與 BSD 程式碼結合，並使用 GCC 作為主要編譯器。這樣一來，NeXT 節省了大量時間，不必從零開始打造所有東西，能專注於打造對客戶重要的使用者介面。Linux 亦是如此，所有以 POSIX 為基礎開發的軟體都能在 Linux 上運行。POSIX 的遵循是出於必要與務實。

與 NeXT 不同，Windows 是從零開始撰寫，沒有考慮 POSIX 相容性。它是建立在功能較弱的 MS-DOS 核心之上的 GUI 層。微軟打造 API 讓程式設計師能在當時剛推出的 Windows 上開發程式。早期 Windows 的 SDK 只有一個標頭檔 <Windows.h>，整個 SDK 可裝入七張 400KB 軟碟，只有兩個標頭檔：STYLE.H 與 WINDOWS.H，Windows.h 只有兩千多行程式碼，是非常精簡的 SDK。

Windows 95 是微軟 32 位元運算的起點，API 也升級以支援 32 位元運算，微軟將新 API 命名為「Win32」。Windows 規模大幅成長，Windows.h 不再是單一標頭檔，而是包含其他子系統的標頭。微軟重寫 Windows 為 Windows NT，API 大致不變，擴展為支援「寬字元」，並開始支援早期 Unicode 編碼。

從此 Windows API 持續擴展。微軟加入了許多新技術，數不清。有時微軟在命名 API 上做得不好。例如 Dynamic Data Exchange 演變成 COM，後來又被品牌化為 OLE 與 OLE Automation，名稱難以理解其功能。這很可惜，因為 COM（或 OLE）是非常有用的技術，但品牌化掩蓋了其可用性，儘管它本身複雜且有許多樣板程式碼。這種模式也被 Mozilla 甚至 Apple 在其驅動框架中模仿。Beno Rice 在一段影片中解釋了這點。

微軟因為有能力，持續新增更多 API，如 CryptoAPI、DirectX 等。Windows 成為豐富的桌面平台，將各種不同 API 打包並統稱為 Windows API。

Windows 以超過 80% 的市場佔有率主導桌面作業系統。隨著 Windows 市場佔有率成長，為 Windows 撰寫的程式也越來越多。許多人只為 Windows 撰寫桌面應用程式，而非為數不清的桌面環境如 GTK 或 Qt 撰寫。程式設計師偏好穩定且可預測的 API，且有豐富的學習資源。微軟在照顧獨立軟體開發商（ISV）方面做得非常好，打造了 Visual Studio 這個卓越的程式開發環境，並成立 MSDN（Microsoft Developer Network），我認為是最完整的 API 文件。

Windows 程式可用，且人們希望在 Linux 等系統上執行它們，因此 WINE 專案誕生。它載入執行檔，並將 Windows API 呼叫轉向 Linux（或 macOS）呼叫。令人驚訝的是，這項努力相當成功，大多數程式都能在 Wine 上運行。一家公司 Codeweavers 將 Wine 打包並以付費方式販售易用版本 CrossOver。我在進行 Windows 復古程式設計時，使用 CrossOver 在 macOS 上測試程式，運行良好且從未失敗過。

Windows 也是遊戲平台。微軟在 Direct3D 與 OpenGL 的 API 戰爭中勝出，微軟在 PC 遊戲領域的主導地位無可爭議。然而，仍有不少用戶希望在 Linux 桌面上執行 Windows。Steam 作為 Windows 遊戲的主要發行管道，實作了自己的 Wine 版本，稱為 Proton，讓原本只為 Windows 撰寫的遊戲能在 Linux 上運行。

Proton 上遊戲的相容率也相當不錯。我嘗試在 Linux 機器上執行《最終幻想 XIII》，成功運行。

Windows 使用可攜式執行檔（Portable Executable）格式，原本只打算在 Windows 上執行，但該格式與 API 現在透過 Wine、CrossOver 或 Proton，普遍可用於三大桌面作業系統。

90 年代與 2000 年初，Java 被推廣為一種可在多平台執行同一程式碼（位元組碼）的平台。這對非 x86 平台確實如此，但在多數情況下，可攜式執行檔「可攜性」更強，因為它能在不修改與重新編譯的情況下執行。如今，你可以在 Linux 與 macOS 上執行原本只為 Windows 撰寫的桌面應用程式。即使 Windows 市場佔有率僅為桌面運算市場的 80%，Windows API 的市場佔有率卻是 100%，因為它能在三大桌面作業系統上運行。

Windows API 與執行檔格式的採用並非由任何標準組織強制推動。事實上，Windows API 仍有未公開的函式與行為，甚至微軟阻止了將其標準化為 ISO 的努力。這種採用是出於必要，人們覺得它有用。

復古程式設計是透過探索舊軟體與硬體來發掘新知識。