If you’ve delved into the world of Linux gaming, you’ve likely encountered the terms “Wine” and “Proton” used interchangeably. While they share a common goal of enabling Windows applications to run on Linux, the intricacies of their functionalities reveal a much deeper story, one that spans over three decades of development and evolution.
Wine isn’t an emulator
It’s a compatibility layer
To clarify, Wine is not an emulator; its name itself is a recursive acronym for “Wine Is Not an Emulator.” Unlike traditional emulators that simulate an entire hardware environment, Wine operates as a compatibility layer. It translates Windows API calls into POSIX equivalents, allowing Windows applications to interact seamlessly with the Linux environment. For instance, when a Windows game requests to create a window, Wine intercepts this call and processes it using Linux’s X11 or Wayland systems. This direct translation enables Wine to deliver performance that can often rival native execution, as it eliminates the overhead associated with emulation.
Proton is built on Wine, but it isn’t Wine
Proton adds a lot for gamers
Valve’s Proton, a compatibility layer designed specifically for running Windows games on Linux through Steam, builds upon Wine’s foundation. It incorporates additional components like DXVK and VKD3D-Proton, which facilitate the translation of Direct3D calls into Vulkan commands. This architecture allows games to communicate directly with the GPU, bypassing the need for emulation layers and enhancing performance. Proton’s integration with Steam simplifies the gaming experience, allowing users to install and play games without needing to understand the underlying complexities.
What should you actually use?
If you’re using Steam, just use Proton
For newcomers to Linux gaming, the plethora of tools available can be overwhelming. However, if you’re gaming on Steam, Proton is the clear choice. It is maintained by Valve and offers a streamlined experience for most games. For those venturing outside the Steam ecosystem, Lutris emerges as a strong alternative, providing a versatile platform that supports various runners, including Wine and Proton, along with automation scripts for game installation.
The long road from 1993 to today
Wine never cracked gaming, but it set the stage
Launched in 1993, Wine has been a monumental effort in reverse engineering, aiming to recreate the Windows API from scratch. Over the years, it has added support for numerous applications, but gaming compatibility remained a challenge. Various forks emerged, attempting to address these limitations, with Cedega being one of the earliest commercial attempts focused on gaming.
Cedega was the early 2000s attempt at Proton
It worked much better than Wine
Cedega, developed by TransGaming, sought to improve upon Wine’s gaming capabilities by focusing on DirectX support and proprietary systems. While it provided a more user-friendly experience for gamers, its subscription model and contentious relationship with the Wine project ultimately led to its decline. In contrast, CodeWeavers’ CrossOver maintained a focus on productivity applications while contributing significantly back to the Wine project, ensuring a symbiotic relationship that benefited the entire community.
From Steam Machines to Proton
And back to Steam Machines
Valve’s initial foray into Linux gaming with Steam Machines highlighted the challenges of a limited game library. This realization prompted the development of Proton, funded by Valve to enhance compatibility for Windows games on Linux. The launch of the Steam Deck further solidified this approach, showcasing the potential for seamless gaming experiences on Linux.
The synchronization problem
A big gaming hurdle for Wine
One of the significant hurdles Wine faced was the synchronization of threads, a critical aspect of modern gaming. Windows uses specific synchronization primitives that Linux does not natively replicate, leading to performance issues. Solutions like esync and fsync emerged to address these challenges, but they were not integrated into vanilla Wine until the introduction of NTSYNC, a new kernel driver that models Windows NT synchronization primitives directly.
Syscall user dispatch and the direct syscall problem
What if a game tries to access the kernel directly?
Another challenge arose when Windows applications attempted to bypass Wine and access the kernel directly. While Proton used seccomp-bpf filters to manage these rogue syscalls, the introduction of syscall user dispatch provided a more elegant solution, allowing Wine to intercept and handle these requests without the overhead associated with previous methods.
Wine and Proton are equally important
Both made Linux gaming what it is today
The evolution of Wine and Proton illustrates the collaborative nature of Linux gaming’s growth. Wine serves as the foundational layer, while Proton enhances the gaming experience, demonstrating how both projects are essential to the current landscape of Linux gaming. Understanding their histories and functionalities provides valuable insight into the tools available today and the ongoing efforts to improve compatibility and performance for gamers on Linux.
