If you've spent any time around Linux gaming, you've probably seen terms like "Wine", and "Proton" tossed around interchangeably, especially a few years ago. The nuances between these tools gets messy fast, and I get why people lump all of them together in the way that they do. After all, they roughly do the same thing from a user's perspective: run Windows stuff on Linux. But the how and why matter enormously, and there are over 30 years of history behind how we got here.

If you just want to know what to use, nowadays, it's a significantly easier question to answer than it used to be. But there's a lot of history that dictates why the entire space looks so confusing from the outside.

Wine isn't an emulator

It's a compatibility layer

Before anything else, it's actually extremely important to know that Wine isn't an emulator. In fact, Wine originally stood for "Wine Is Not an Emulator," and yes, it was a recursive acronym, but it's a big part of how and why Wine works.

An emulator, like you might find in RetroArch, simulates the entire hardware environment. It pretends to be a different machine entirely, translating every instruction the guest software tries to run into instructions the host machine understands. When a PS2 emulator runs a game, it's pretending to be a MIPS processor, and it's computationally expensive because you're running a fake computer inside your real one.

Wine does something fundamentally different. Instead of emulating hardware, it's a compatibility layer that translates Windows API calls into their POSIX equivalents. When a Windows game asks Windows to "create a window with these dimensions," Wine intercepts that call and handles it using Linux's X11 or Wayland. When a game wants to load a texture, Wine translates that request into something Linux's graphics stack understands. It doesn't simulate an Intel processor or pretend to be Windows. It just translates the language the software speaks into something Linux understands.

This is why Wine can be surprisingly fast. There's no emulation overhead eating up your CPU cycles. For many applications, you're looking at near-native performance because, in a very real sense, the code is running natively on your actual hardware. It's just being passed through a layer that translates from one language to another on the fly. That said, real-world performance varies significantly depending on workload, graphics API path, driver quality, and how well Wine implements the specific Windows behaviors an application depends on.

The actual mechanism is worth understanding too. Windows executables are Portable Executable (PE) files, a format that bundles executable code with metadata and resources. Wine loads these PE files directly and executes their native machine code on your actual CPU. It only intercepts the operating system calls, the requests the program makes to interact with Windows itself. Most of the actual computation happens at native speed on your hardware.

Proton is built on Wine, but it isn't Wine

Proton adds a lot for gamers

Proton is Valve's compatibility stack for running Windows games through Steam on Linux. It's built on Wine, but it also includes DXVK and VKD3D-Proton for Direct3D translation, Steam-specific fixes, controller integration, fullscreen handling, and other patches. It isn't just Wine with a different name.

The biggest addition Proton brought was DXVK, a Vulkan-based translation layer for Direct3D 9, 10, and 11. Direct3D is Windows's graphics API, and most PC games use it exclusively. Direct3D calls have to go somewhere, and on Linux, the most practical modern target is Vulkan. DXVK translates those Direct3D calls to Vulkan, which Linux handles natively and efficiently. For Direct3D 12, there's VKD3D-Proton, which serves the same purpose.

All of this is a big deal as it means games can talk to your GPU without going through emulation layers, but rather, an architecturally simpler translation layer that takes function calls destined for DirectX and sends your GPU Vulkan commands instead. Your GPU gets a function call that it's designed to receive, and the translation happens at the API level rather than the hardware level.

Proton also included sensible defaults out of the box, automatic configuration per game, Steamworks integration for multiplayer, and OpenVR support for VR titles. The idea was that you shouldn't need to understand what was happening under the hood. All of this means you can install a game, then just play the game.

What should you actually use?

If you're using Steam, just use Proton

If you've just switched to Linux and searched for how to run a Windows game, you've probably found five different tools recommended across three different forum threads, none of which agree on which one to use. That confusion is a direct result of decades of development, multiple forks, and different projects solving different parts of the problem. It makes more sense once you know why all these tools exist, but it doesn't make the initial experience any less overwhelming.

If you're gaming on Steam, just use Proton. It's already integrated, Valve maintains it, and you don't need to think about it. The Steam Deck experience is proof that it works incredibly well for the vast majority of games.

If you're outside Steam, Lutris is probably your best bet. It can use Wine, Proton, Proton-GE, and other community runners alongside install scripts that automate the configuration process for thousands of games. If a game isn't in Steam's official compatibility list, Lutris probably has a script for it. The interface is more involved than Steam's plug-and-play approach, but it's gotten significantly better over the years.

Bottles takes a different approach with a more polished interface. It's a Wine prefix manager that supports multiple runner families, including Bottles' own runners, Lutris runners, and Proton-GE. You pick the runner depending on what works best for the application. It's popular with people who want to run Windows software outside Steam without diving into configuration files.

And if you're a power user who wants the latest and greatest, Proton-GE is a community-maintained fork that rebases to more recent Wine versions faster than Valve's official releases. It also includes additional patches and features that haven't made it into Proton proper yet. It's not officially supported, and Valve doesn't maintain it, but for enthusiasts it's often the path to better compatibility with stubborn games.

CodeWeavers still maintains CrossOver, their commercial product focused on productivity applications. It's less relevant for gaming than it used to be, but if you need to run Microsoft Office or QuickBooks on Linux or macOS, CrossOver remains the smoothest option. And critically, CodeWeavers continues to contribute heavily to Wine upstream, so their work benefits everyone.

The long road from 1993 to today

Wine never cracked gaming, but it set the stage

Wine began in 1993, which makes it older than most of the games it's used to run. The project was started by Bob Amstadt and Eric Youngdale, with Alexandre Julliard taking over leadership in 1994. It grew slowly at first into one of the most ambitious reverse engineering projects ever attempted. The goal was simple but enormous: recreate the entire Windows API from scratch, one function at a time.

What does that actually mean in practice? While Microsoft has published extensive Win32 API documentation for decades, reproducing that specification accurately is a different challenge entirely. The Wine community had to figure out the exact behavior including edge cases, undocumented internals, and how applications depended on quirks and bugs in Windows' actual implementation. They weren't just reading documentation and implementing it, as they also had to verify that their implementation behaved exactly as the Windows APIs did in practice.

Over the years, Wine tackled piece after piece of the Windows API. Kernel32 for core system functions. User32 for windows and input. Gdi32 for graphics. Advapi32 for security and registry. Ntdll for the deep kernel-level calls. Each library added support for thousands of applications that suddenly worked on Linux.

The project reimplements Windows behavior without using Microsoft code. Microsoft never officially sanctioned Wine, but they also never successfully killed it. Unfortunately, what Wine never quite cracked on its own was gaming. There were quite a few reasons for this limitation, but that's where the forks come in.

Cedega was the early 2000s attempt at Proton

It worked much better than Wine

The first major fork was TransGaming's Cedega, which launched in the early 2000s as a commercial product focused specifically on games. At the time, Wine's DirectX support was notoriously bad, and Cedega took the Wine code and rewrote it with gaming in mind. Cedega also focused on copy-protection handling and proprietary systems like Gamespy's matchmaking, which Wine didn't support at all.

Cedega was subscription-based, around $5 per month with a minimum three-month commitment, and it worked surprisingly well for a lot of games. World of Warcraft ran on it. Half-Life 2 ran on it. Battlefield 2 ran on it. For a long time, if you wanted to play Windows games on Linux and didn't want to wrestle with configuration files, Cedega was the answer.

But Cedega had problems. The subscription model grated on users who felt they were paying monthly for a software package that should be free. TransGaming's relationship with the Wine project was also contentious, with code flowing in one direction in a way that enabled a company to profit off of the project, but code rarely went back towards bettering the project as a whole. Cedega stayed ahead on gaming compatibility for a while, but as Wine improved, the gap narrowed.

The real blow came in 2002 when Wine changed its license from the X11 license to the LGPL. This was specifically intended to make proprietary downstream forks less attractive by requiring them to publish changes to LGPL-covered components. Cedega, which had built proprietary code on top of Wine's earlier permissive license, was forced to maintain its own codebase separately. The LGPL switch made long-term proprietary divergence less attractive, and Cedega was already facing other business and technical pressures. The service shut down in 2011, replaced briefly by GameTree Linux before that too faded away.

The other commercial fork was CrossOver, from CodeWeavers. Where Cedega focused on games, CodeWeavers focused on productivity applications. Microsoft Office, Quicken, and Adobe's Photoshop were prime candidates, as they were applications that businesses actually needed. CrossOver wrapped Wine in a user-friendly interface and charged for it, with support included.

Here's the thing about CodeWeavers though: they contributed heavily back to Wine upstream. Unlike TransGaming's insular approach, CodeWeavers understood that the health of the Wine project mattered for their own business. Most of what CrossOver improved eventually made its way back to WineHQ proper. This made CodeWeavers the de facto corporate steward of Wine development for years, long before Valve showed up.

From Steam Machines to Proton

And back to Steam Machines

Valve's interest in Linux gaming didn't start with Proton. In 2015, it launched Steam Machines, a line of Linux-based gaming PCs running SteamOS. The hardware was fine, but the game library wasn't there. SteamOS depended on developers shipping native Linux ports, and most simply didn't. The Steam Machine lineup quietly disappeared, and the common takeaway was that Linux wasn't ready for gaming. But Valve drew a different conclusion: waiting for developers to come to Linux wasn't going to work. If Windows games could just run on Linux as-is, the library problem goes away.

That thinking produced Proton. In August 2018, Valve announced Steam Play and Proton, and it genuinely marked a before-and-after moment for Linux gaming. Valve has funded CodeWeavers' work on Proton since the beginning. CodeWeavers had been working on Wine for years as a commercial venture, but Valve's money turned it into something different. Suddenly there were full-time developers paid specifically to improve gaming compatibility, with Valve's interests aligned with making Windows games work on Linux.

The Steam Deck launched in 2022 and made all of this tangible. Here was a handheld gaming device that ran Linux, and thanks to Proton, it played most Windows games without the user needing to know anything about Wine, DXVK, or synchronization primitives. The Steam Deck served as proof that Proton worked, the approach was sound, and Linux gaming could be invisible the way Valve intended. That's also likely to be a big part of why Valve's Steam Machine is making a comeback, though the current DRAM crisis is making it difficult to actually start selling the thing.

The synchronization problem

A big gaming hurdle for Wine

To understand the modern issues that Wine faces today, you need to grasp the concept of synchronization primitives to understand one of the biggest.

When a modern Windows game runs, it's not doing one thing at a time. Your CPU is juggling rendering, physics calculations, asset streaming, audio processing, and AI routines all at once, across multiple threads. These threads need to coordinate constantly. One thread might need to wait for another to finish loading a texture before it can render a frame. Another might need exclusive access to a shared resource so two threads don't try to modify it simultaneously.

Windows handles this coordination through NT synchronization primitives: mutexes, semaphores, events, and the like. They're baked deep into the Windows kernel, and games rely on them heavily. Windows games assume these primitives work exactly as Windows implements them, with specific timing and behavior.

Linux doesn't have native equivalents that behave exactly the same way. This created a fundamental mismatch that Wine had to work around.

The original Wine approach involved making a round-trip call to a dedicated fake kernel process called wineserver for many synchronization operations. Picture a restaurant where every time the kitchen needed to coordinate with the bar, they had to run outside to a central manager's office, get permission, then run back. For a game making thousands of synchronization calls per second, that overhead can (and did) add up fast. It was noticeable too, as it manifested in subtle frame stutters, inconsistent frame pacing, and games that just felt slightly off.

Elizabeth Figura, a developer at CodeWeavers, started working on this problem. Her first solution was esync, which used Linux's eventfd system call to handle synchronization without bouncing through wineserver. Instead of running to the central manager every time, threads could talk to each other directly through a Linux mechanism that was actually designed for this purpose. It worked, and it helped noticeably, but some distros ran into issues with file descriptor limits because every synchronization object needed its own file descriptor.

Fsync came next, using Linux futexes for even better performance. Early on, it depended on out-of-tree kernel patches that added a custom FUTEX_WAIT_MULTIPLE operation, which made it less accessible on mainstream distros. That changed once Linux 5.16 added futex_waitv() to mainline. This was a proper upstream syscall developed by André Almeida at Collabora that solved the same problem in a cleaner way. Newer Proton builds dropped the old out-of-tree interface entirely and switched to futex_waitv(), but the community kept calling it "fsync" regardless, and the name stuck even though the plumbing underneath was completely different. There was a transitional mess too: mismatches between the old kernel patches and newer fsync code could cause problems like runaway CPU usage, and users had to make sure both their kernel and their Wine or Proton build supported the same interface.

Both esync and fsync were clever workarounds to a real problem, but the fact is that neither ever came enabled in vanilla Wine. Esync and fsync lived as out-of-tree patches. If you installed Wine from your distro's package manager, you didn't get them. You needed Proton, a community fork like wine-tkg, or to compile Wine yourself with the patches applied. A newcomer who installed Wine through apt or dnf to try running a game would have been stuck on the old wineserver model without ever knowing something better existed. And that brings us to Wine 11.

NTSYNC and the kernel rewrite

Let the Linux kernel handle it instead

One of the big recent improvements around Wine 11 is NTSYNC, a new kernel driver that directly models Windows NT synchronization primitives at the kernel level. Instead of trying to approximate NT synchronization behavior using Linux primitives that weren't designed for the job, it adds a /dev/ntsync device that Wine can talk to, and the kernel itself handles the coordination.

The difference, to use the same restaurant metaphor, is like finally getting that central manager's office relocated inside the restaurant. Everything happens faster because the infrastructure is actually designed for the task.

The numbers speak for themselves, and are a testament to just how necessary this problem was to solve. In benchmarks comparing vanilla Wine to NTSYNC-enabled Wine, Dirt 3 jumped from around 110 FPS to 860 FPS. Resident Evil 2 went from 26 FPS to 77 FPS. Tiny Tina's Wonderlands saw improvements from 130 FPS to 360 FPS. To be clear, these numbers are comparing NTSYNC against vanilla Wine without esync or fsync enabled, so if you're already using fsync, the gains won't be anywhere quite that dramatic, and might even be invisible.

However, what makes NTSYNC special isn't just the performance. It's that it's actually in the mainline Linux kernel now, starting with version 6.14, and it's part of vanilla Wine. You don't need custom patches, out-of-tree modules, or even a custom Wine build. Valve has already loaded the NTSYNC module by default in SteamOS 3.7.20 beta.

That's a big deal for most people, because as Proton picks up newer Wine code over time, Steam Deck owners will eventually get these improvements through a SteamOS update. The gains won't be universal or dramatic for everyone, since Proton already had fsync-based approaches in place, but it's a move towards a standardized synchronization interface that's more in-line with vanilla Wine than any other previous attempt at solving the problem.

Syscall user dispatch and the direct syscall problem

What if a game tries to access the kernel directly?

NTSYNC solved the synchronization bottleneck, but there was another kernel-level problem lurking underneath: what happens when Windows software bypasses Wine entirely and issues a raw x86 syscall instruction?

Normally, Wine intercepts Windows API calls through its own reimplemented DLLs. A game calls a function in ntdll.dll, Wine's version of that DLL catches it, and everything gets routed correctly. But some Windows software skips the DLL layer and issues direct NT syscall instructions instead. On real Windows, the NT kernel handles those. On Linux, they hit the Linux kernel instead, which sees a completely different syscall numbering scheme. The result is a crash or silent corruption.

Proton had been working around this for years using seccomp-bpf filters to intercept those rogue syscalls and redirect them. It worked, but seccomp is a blunt instrument. Once installed, it can't be removed. It lacks fine-grained, per-thread control. And it carries overhead for every syscall, not just the ones that need interception.

Syscall user dispatch, which landed in the Linux kernel back in 5.11, is the cleaner solution. It lets a process choose between native and emulated syscall handling. When Wine's own native code needs to talk to the Linux kernel, it allows syscalls pass through normally. When Windows code runs and might issue a direct NT syscall, it blocks the requests and the kernel delivers a signal instead, letting Wine intercept and handle it. There's no kernel call needed to switch modes either, as it's just a write to memory.

Despite being available in the kernel since 2021, mainline Wine didn't adopt it until 11.5 in March 2026. That five-year gap is another example of how kernel features and user-space support have to converge before anything actually changes for users. Games like Detroit: Become Human and Red Dead Redemption 2 that depended on direct syscalls now work in mainline Wine, not just Proton.

Wine and Proton are equally important

Both made Linux gaming what it is today

The distinction between Wine and Proton is important, given that both grew out of different needs and goals. Wine is the foundation that everything builds on, a compatibility layer started in 1993 that reimplements the Windows API one function at a time. Proton is the gaming-focused compatibility stack built on top of it, funded by Valve after the Steam Machine's failure taught them that waiting for native ports wasn't going to work.

Understanding that history explains why the ecosystem looks the way it does: why there are so many tools, why CodeWeavers matters, why Cedega died, why synchronization primitives took decades to solve properly, and why improvements like NTSYNC and syscall user dispatch are only now landing in vanilla Wine. For years, the best gaming experience lived in forks and patches that most users never knew about.

That gap has been shrinking more and more over the years, and it's because of both Wine and Proton.