翻译层如何重塑计算领域并普惠大众？
在计算领域，翻译层已成为一项至关重要的技术，改变了我们如今与技术互动的方式。这些层本质上使得软件能够在原本并非为其设计的硬件和操作系统上运行，已成为跨平台兼容性的关键部分。它们不仅有助于保留遗留应用程序，还使无论您使用何种机器都能平等地访问软件。
如今，翻译层以诸如 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 能够以现有的形式存在的唯一原因，也是向苹果硅芯片过渡变得容易的一个重要部分。软件翻译是一项极其重要和令人兴奋的发展，而且随着时间的推移只会变得越来越好，我很期待看到它随着时间的推移如何改进。