翻譯層如何重塑計算領域並普惠大衆？
在計算領域，翻譯層已成爲一項至關重要的技術，改變了我們如今與技術互動的方式。這些層本質上使得軟件能夠在原本並非爲其設計的硬件和操作系統上運行，已成爲跨平臺兼容性的關鍵部分。它們不僅有助於保留遺留應用程序，還使無論您使用何種機器都能平等地訪問軟件。
如今，翻譯層以諸如 MacOS 上的 Rosetta 2 或 Steam Deck 上的 Proton 等軟件的形式出現，但翻譯層在很多方面使其成爲 2024 年正在開發的最有趣和最重要的軟件之一。翻譯層的悠久歷史真正始於 20 世紀 90 年代，隨着 Wine（最初爲 WINE，代表 Wine Is Not an Emulator）和 Sun Microsystems 的 Wabi 的發佈。
如果您從語言的角度來思考計算機和操作系統，翻譯層本質上是獲取爲不同類型的機器和軟件構建的軟件，並實時爲您實際嘗試運行它們的任何設備進行翻譯。這個概念已經存在了很長時間，並且與仿真不同。仿真是試圖在虛擬環境中爲軟件的運行重新創建合適的條件，而翻譯則在軟件和計算機之間運行，將每個指令重定向到其實際運行的操作系統上的適當位置。
就 Sun Microsystems 的 Wabi 而言，它是爲 Unix 操作系統 Solaris 開發的，旨在運行爲 Windows 3.1、Windows 3.11 和 Windows for Workgroups 構建的應用程序。它實現了 Windows Win16 API，並解釋和翻譯指令，以便爲 Windows 開發的軟件仍能在其自己的操作系統上運行。同年，Wine 發佈，其靈感來自 Wabi 和公共 Windows 接口，這是試圖在公共領域將 Windows API 作爲 ISO 標準完全實現。
Wine 最初瞄準的是 16 位的 Windows 3.x 軟件，實現了對 Windows API 的支持並對其進行轉換。
本質上來說，專爲 Windows 編寫的應用程序只能在 Windows 系統上運行，因爲它們指望使用 Windows API。
像 Wine 這類應用程序知曉這些應用程序的需求以及它們在 Linux 中的對等項。
Wine 會執行該應用程序，在運行應用程序期望從常規 Windows 系統獲取的後臺軟件的同時，把應用程序所需的一切都重定向到 Linux 的等效項上。
例如，想象一個 Windows 應用程序需要在屏幕上創建一個包含用戶信息的消息框。這會調用 MessageBox Windows API，不過 Linux 機器顯然無法理解 Windows API。Wine 接收到創建 MessageBox 的請求，並明白在 Linux 機器上（通過 Xlib）的對等項或許是 XCreateSimpleWindow。然後它明白用於在 Windows 上調用 MessageBox 的參數能夠取而代之被提供給 XCreateSimpleWindow。一旦用戶與它進行交互（比如，通過點擊按鈕），結果就會返回給 Wine，並轉換回應用程序期望從 Windows 機器獲取的格式（通過 MessageBox 函數）。
Steam Deck 和蘋果最新的 Mac 是嚴重依賴翻譯層的產品的例子，不過在後者的情況中，如今並非這般。Steam Deck 使用 Proton，這是一個基於 Wine 的翻譯層。Proton 比 2018 年 8 月首次發佈的 Steam Deck 早幾年。當時，Valve 表示：“目前沒有 Linux 版本的 Windows 遊戲現在可以直接從 Linux Steam 客戶端安裝和運行，並具有原生的 Steamworks 和 OpenVR 支持。”
然而，Proton 對於遊戲等式至關重要的另一方面是其翻譯 Direct3D API 調用的能力。它包括 DXVK，這是一個基於 Vulkan 的 Direct3D 9、10 和 11 的翻譯層，通過 VKD3D-Proton（Wine 的 VKD3D 的分支）提供對 Direct3D 12 的支持。這意味着遊戲可以在它們原本不支持的平臺上運行，因爲它接收那些直接的函數請求並將它們翻譯成在 Linux 上可行的等效項。
所有這些都會導致性能下降，但遠不及虛擬化 Windows 11 所帶來的開銷。事實上，有些人甚至注意到在 Steam Deck 上的 Proton 中運行遊戲比在 Steam Deck 上的 Windows 中運行更好，因爲在 Steam Deck 上運行 Windows 的計算開銷可能超過實時翻譯的性能損失。艾爾登法環 就是一個例子。
來源：Sydney Louw Butler / XDA
這意味着硬件開發商無需再向微軟支付在遊戲手持設備或其他機器上使用 Windows 的許可費用。此外，這使得 Windows 有了一個不斷增長的競爭對手，因爲既然遊戲最終能夠在該平臺上運行，遊戲玩家可能會轉向 Linux。在競爭操作系統上不斷增長的玩家基礎鼓勵開發者爲該操作系統原生編譯他們的遊戲，這將總體上獲得更好的性能，並且最終對最終用戶來說不那麼棘手。
Rosetta 2 與 Proton 截然不同，原因在於其進行的翻譯工作有所不同。
Rosetta 並非是將 Windows 翻譯爲 MacOS，而是把 x86_64 翻譯爲 Arm，從而保證您在基於英特爾的舊款 Mac 上運行的程序，如今在基於 Arm 的 Mac 上依然能夠運行。
蘋果於去年 6 月發佈了遊戲移植工具包，給開發者提供了一種能在 Mac 上快速測試其遊戲，以查看運行效果的辦法。
要是沒有翻譯，您那基於 Arm 的 Mac 裡的處理器就無法理解爲基於英特爾的 Mac 所構建的應用程序，而且 Arm 處理器要麼不能理解針對英特爾 CPU 的指令，要麼可能會執行不一樣的操作，因爲相同的二進制代碼在每個 CPU 上代表的指令是不同的。
然而，更令人驚歎的是，與 Proton 不同，這裡也有架構轉換。這些遊戲仍然在蘋果硅芯片上運行，所以它們不僅是爲 Windows 構建的，也是爲 x86_64 構建的。它還必須再採取 另一個 步驟，將 x86 轉換爲 Arm，這意味着要從 x86_64 轉換爲 Arm，從 Windows API 調用轉換爲 MacOS API 調用，從 Direct3D 調用轉換爲 Metal。遊戲 能夠運行 這一事實本身就令人印象深刻，但更令人驚奇的是這些遊戲運行得非常好。當時我能夠玩 《賽博朋克 2077》 相當長一段時間，還有 《蜘蛛俠：邁爾斯·莫拉萊斯》 。
因此，軟件翻譯顯然正在改變我們如今看待計算的方式。它不僅迫使開發者在開發應用程序和遊戲時考慮其他系統，而且還意味着消費者可以隨意更換平臺，而不必擔心無法使用他們日常使用的應用程序和遊戲。這是 Steam Deck 能夠以現有的形式存在的唯一原因，也是向蘋果硅芯片過渡變得容易的一個重要部分。軟件翻譯是一項極其重要和令人興奮的發展，而且隨着時間的推移只會變得越來越好，我很期待看到它隨着時間的推移如何改進。