In the computing world, translation layers have become a vital technology that has transformed how we interact with tech today. These layers, essentially allowing for software to run on hardware and operating systems that it wasn't designed to run on, have become a critical part of cross-platform compatibility. Not only do they help to preserve legacy applications, they also democratize access to software no matter the machine you're using.

Nowadays, translation layers come in the form of software like Rosetta 2 on MacOS or Proton on the Steam Deck, but there's a lot to translation layers that make them some of the most interesting and most important software being developed in 2024. The long history of translation layers really took off in the 1990s, with the release of Wine (originally WINE, standing for Wine Is Not an Emulator) and Wabi from Sun Microsystems.

Translation layers, how they work, and their history

Think of it like languages

If you think about computers and operating systems in terms of languages, translation layers essentially take software built for different kinds of machines and software and translate them in real-time for whatever you're trying actually to run them on. This concept has been around for quite a long time and is distinct from emulation. Emulation tries to recreate the correct conditions in a virtual environment for the software to run in, whereas translation runs between the software and the computer, redirecting each instruction to the machine to the appropriate location on the operating system it's actually running on.

In the case of Wabi from Sun Microsystems, it was developed for Solaris, a Unix operating system, and was designed to run applications built for Windows 3.1, Windows 3.11, and Windows for Workgroups. It implemented the Windows Win16 API and interpreted and translated instructions so that software developed for Windows would still run on its own operating system. In the same year, Wine was released, inspired by Wabi and the Public Windows Interface, an attempt to get the Windows API fully implemented as an ISO standard in the public domain.

Wine originally targeted 16-bit Windows 3.x software, implementing support for Windows APIs and translating them. It translates Windows API calls to POSIX (Portable Operating System Interface) calls while also recreating a Windows directory structure and providing alternative implementations of system services. Wine doesn't use any emulation or virtualization to execute Windows binaries.

In essence, applications written for Windows can only run on Windows as they expect to use the Windows API. Applications like Wine understand what these applications are looking for and their Linux equivalents. Wine will execute the application, redirecting everything the application needs to Linux equivalents while running the background software that the application expects from a regular Windows system, too. No emulation or virtual environment is required either.

As an example, imagine a Windows application needs to create a message box on the screen containing information for the user. This invokes the MessageBox Windows API, but a Linux machine obviously won't understand the Windows API. Wine sees the request to create a MessageBox, and understands that the equivalent on Linux machines (via Xlib) might be XCreateSimpleWindow. It then understands that the parameters being used to invoke the MessageBox on Windows can instead be taken and given to XCreateSimpleWindow. Once the user interacts with it (for example, by clicking a button) the result then goes back to Wine and is translated back into a format (through the MessageBox function) that the application expects from a Windows machine.

How translation layers are changing computing

The Steam Deck and Apple Silicon are examples of products that are impossible without it

The Steam Deck and Apple's newest Macs are examples of products that heavily rely on translation layers, though ot so much in the latter case these days. The Steam Deck uses Proton, a translation layer that builds on top of Wine. Proton is a few years older than the Steam Deck, which was first released in August 2018. At the time, Valve said that "Windows games with no Linux version currently available can now be installed and run directly from the Linux Steam client, complete with native Steamworks and OpenVR support."

However, the other side of Proton that's essential to the gaming equation is its ability to translate Direct3D API calls. It includes DXVK, a Vulkan-based translation layer for Direct3D 9, 10, and 11, with support for Direct3D 12 provided via VKD3D-Proton, a fork of VKD3D from Wine. This means that games can run on a platform they were never meant to, as it takes those direct function requests and translates them to equivalents that will work on Linux.

With all of those comes a performance hit, but nowhere near the overhead that you would experience from virtualizing Windows 11. In fact, some people have even noticed that games run better in Proton on the Steam Deck than on Windows on the Steam Deck, as the computational overhead of running Windows on the Steam Deck can outweigh the performance loss from real-time translation. Elden Ring is an example of that.

What this means is that hardware developers no longer need to pay Microsoft for licensing Windows on a gaming handheld or other machine, as a translation layer ensures that games can be expected to run reasonably well. Plus, this enables a growing competitor to Windows, as gamers may make the switch to Linux given that games can finally run on the platform. A growing player base on a competing operating system encourages developers to compile their games for that operating system natively, which will net better performance overall and is ultimately less finicky for an end user.

Rosetta 2 is an entirely different beast from Proton, though, and that's because the translation that it does is different. Rather than translating from Windows to MacOS, Rosetta translates from x86_64 to Arm, ensuring that your programs that ran on older Intel-based Macs can still run on your Arm-based one today. It's a complicated process, as it translates on a processor level.

Without translation, the processor in your Arm-based Mac would not understand applications built for Intel-based Macs, and the Arm processor either wouldn’t understand the instruction meant for an Intel CPU or might perform a different operation because the same binary code represents different instructions on each CPU.

Apple's Game Porting Toolkit is a combination of both

It's a marvel of technology

Apple released the Game Porting Toolkit in June last year, giving developers a way to quickly test their games on Mac to see how well they would run. On the surface, it works similarly to Proton on the Steam Deck. It makes use of Wine as a base to translate Windows API calls to POSIX (Portable Operating System Interface) calls and then translates DirectX calls to Apple's Metal API. Wine recreates a Windows directory structure and provides alternative implementations of system services, and it doesn't use any emulation or virtualization to execute Windows binaries.

However, where things get even more amazing is that, unlike Proton, there's an architectural conversion here too. These games are still running on Apple Silicon, so not only are they built for Windows, they're built for x86_64, too. It has to take another step to translate from x86 to Arm, meaning that you're converting from x86_64 to Arm, from Windows API calls to MacOS API calls, and from Direct3D calls to Metal. The fact games work at all is impressive, but what's even more amazing is that those games run very well. I was able to play Cyberpunk: 2077 for quite a while at the time, along with Spider-Man: Miles Morales.

With that, software translation is clearly changing how we look at computing today. Not only does it force developers to think of other systems when they develop their applications and games, but it also means that consumers may feel free to change platforms without worrying about losing access to the applications and games they use on a daily basis. It is the sole reason that the Steam Deck can exist in the form that it does, and it's a huge part of what made the transition to Apple Silicon easy. Software translation is an incredibly important and exciting development that's only getting better with time, and I'm excited to see how it improves as time goes on.