Proton vs Wine: Choosing the Right Compatibility Layer

If you've spent any time around Linux gaming, you've seen Wine and Proton used almost interchangeably in forum posts and install guides. The confusion is understandable: both tools make Windows software run on Linux, and Proton is literally built on Wine. But they are not the same thing, and the distinction matters when you're choosing how to run a specific piece of software.

The short version: Wine is the foundational compatibility layer that translates Windows API calls into Linux system calls. Proton is a gaming-focused stack Valve built on top of Wine that adds DirectX translation via Vulkan, synchronization improvements, Steam integration, and per-game configuration. For Steam games, Proton is almost always the better choice. For everything else -- non-Steam games, legacy productivity software, enterprise applications -- you're working with Wine directly, usually through a front-end like Lutris or Bottles.

This article covers how both work at a technical level, what changed with Wine 11's January 2026 release, when to use each, and how the surrounding tooling ecosystem fits together.

Wine: The Foundation

Wine has been in development since 1993. The name originally expanded to "Wine Is Not an Emulator" -- a recursive acronym that also makes the important architectural point. Wine does not run a Windows virtual machine. It does not execute Windows kernel code. Instead, it reimplements the Windows API surface as a compatibility layer that translates Windows function calls into POSIX system calls that Linux understands, in real time as the application runs.

The consequence of this approach is that Wine programs run at native speed without hardware virtualization overhead. A Windows executable running under Wine makes the same system calls a native Linux process would -- Wine just intercepts and translates them before they reach the kernel. This is architecturally efficient, but it requires Wine to correctly implement every piece of the Windows API surface that any given application uses, which is an enormous and ongoing engineering effort spanning over three decades.

When you run Wine directly without any front-end, you use a Wine prefix -- a directory containing a simulated Windows C: drive, a Windows registry, and the installed application data. By default this lives at ~/.wine, but you can set the WINEPREFIX environment variable to any path, which lets you maintain isolated environments for different software:

# Create an isolated prefix for a specific game
$ export WINEPREFIX=~/.wine-game-x
$ wineboot        # initialize the prefix

# Install dependencies into that prefix
$ WINEPREFIX=~/.wine-game-x winetricks vcrun2019 d3dx11

# Run a game from that prefix
$ WINEPREFIX=~/.wine-game-x wine /path/to/game.exe

# Open Wine configuration for that prefix
$ WINEPREFIX=~/.wine-game-x winecfg

Using separate prefixes per application is important practice. Mixing multiple games or programs in a single prefix leads to DLL conflicts: game A might require a specific version of a Visual C++ runtime that breaks game B, or two programs might write conflicting registry entries. Front-ends like Lutris and Bottles manage prefix isolation automatically.

Wine 11: What Changed in January 2026

Wine 11.0 shipped on January 13, 2026, after a year of development and more than 6,300 changes. Two architectural features define this release: NTSYNC and the completed WoW64 overhaul. Both have meaningful implications for gaming.

NTSYNC: Synchronization Rewired at the Kernel Level

To understand why NTSYNC matters, you first need to understand what it replaced. Windows games are heavily multi-threaded: physics, AI, audio, and rendering all run on separate threads that need to coordinate without stepping on each other. They do this using Windows NT synchronization primitives -- mutexes, events, semaphores. Wine had to approximate this behavior using Linux primitives that were not designed for the job.

The original Wine approach sent every synchronization call through a round-trip to a dedicated process called wineserver. The wineserver is a persistent background process that Wine spawns per-prefix to handle operations that require a "kernel" in the Windows model -- synchronization objects, process and thread management, registry writes, and inter-process communication. Because it runs as a separate Unix process, every synchronization call requires a context switch and an inter-process communication round-trip. For a game making thousands of synchronization calls per second, that overhead accumulated into real stutter and frame pacing inconsistencies -- games that felt subtly wrong even when average FPS numbers looked acceptable.

Two workarounds emerged over the years:

• esync -- developed by Zeb Figura at CodeWeavers, used Linux eventfd to handle synchronization without wineserver round-trips. It helped substantially, but every synchronization object needed its own file descriptor, and games opening many of them could hit system-level descriptor limits.
• fsync -- used Linux futexes for better performance than esync in most cases. The original implementation required the futex_wait_multiple operation, which relied on out-of-tree kernel patches that never made mainline. Later versions switched to futex_waitv(), which André Almeida at Collabora contributed to mainline Linux 5.16 (January 2022), making the modern fsync implementation accessible without custom kernel builds. The community continued calling the feature "fsync" even after the underlying mechanism changed.

Both were workarounds. They approximated NT synchronization behavior well enough for most games, but could not correctly handle certain edge cases -- operations like NtPulseEvent() and the "wait-for-all" mode in NtWaitForMultipleObjects() that require direct kernel-level control over wait queues.

NTSYNC takes a completely different approach. Instead of approximating NT synchronization with existing Linux primitives, it adds a new kernel driver that directly models Windows NT synchronization objects. Figura -- the same engineer who built esync and fsync -- iterated on the kernel patch set for years, presented the work at Linux Plumbers Conference in 2023, and pushed it through multiple revision cycles before it was merged into mainline Linux kernel 6.14.

Developer benchmarks comparing NTSYNC against vanilla upstream Wine (with neither esync nor fsync) showed results that originally appeared on LWN.net alongside Figura's kernel patch submissions: Dirt 3 went from 110.6 FPS to 860.7 FPS (a 678% improvement), Call of Juarez from 99.8 to 224.1 FPS, Tiny Tina's Wonderlands from 130 to 360 FPS, and Resident Evil 2 from 26 to 77 FPS. Call of Duty: Black Ops I moved from effectively unplayable to functional under NTSYNC -- a qualitative shift, not just a frame rate number. These figures compare against the worst-case scenario -- upstream Wine with no synchronization workarounds at all. For users already on Proton with fsync enabled, the real-world gain is more modest but meaningfully real, particularly for games with heavy multi-threaded workloads. NTSYNC is also semantically correct in ways fsync never was, which means edge cases that caused subtle behavior differences are now handled properly. As Adam Conway noted in his March 2026 XDA Developers analysis of Wine 11: NTSYNC is "the first time Wine's synchronization has been correct at the kernel level."

WoW64: Completed Architecture

WoW64 ("Windows 32-bit on Windows 64-bit") is the mechanism that lets 64-bit systems run 32-bit applications. Wine has been building a new WoW64 architecture since version 9.0, and Wine 11.0 marks it as fully supported. The practical benefit is that 32-bit Windows programs now run on a 64-bit Wine installation without requiring any 32-bit system libraries on the host -- many Linux distributions no longer ship these by default, which had been a significant source of compatibility friction for older games and software.

Wine 11 also drops the separate wine64 binary in favor of a single loader that automatically selects 32-bit or 64-bit mode based on what it's running. 16-bit applications work in the new WoW64 mode as well, which matters for software preservation and legacy DOS-era game compatibility.

One practical consequence: Wine 11 removes support for new pure 32-bit prefixes created with WINEARCH=win32. Existing 32-bit prefixes continue to work, but new prefixes should use WINEARCH=wow64 to get the new architecture. Front-ends like Lutris and Bottles handle this automatically for new bottles.

Wayland Driver: Matured in Wine 11

Wine 11.0 significantly advanced its experimental Wayland driver, which is relevant for users running Linux distributions that have moved away from X11 or are running in Wayland sessions by default (including Fedora 40+ and Ubuntu 24.04 with GNOME). The Wine 11.0 Wayland driver adds clipboard support, input method support, shaped and color-keyed window support, and a shift to shared-memory communication between processes that reduces the CPU cost of basic windowing operations. The Wayland driver remains labeled "experimental" -- not all Wine applications will work correctly under it -- but it is stable enough for a growing range of games and tools. Users who encounter rendering or input issues under Wayland can still run Wine applications through XWayland, the X11 compatibility layer that ships with every Wayland compositor.

Wine 11.5 and Syscall User Dispatch

The development branch continued moving quickly after the 11.0 stable release. Wine 11.5, released March 20, 2026, introduced Syscall User Dispatch support in NTDLL. This addresses a different class of compatibility problem from NTSYNC: some Windows software -- particularly DRM-protected games and anti-cheat systems -- bypasses the DLL layer entirely and issues raw x86_64 SYSCALL instructions. On real Windows, those syscalls land in the NT kernel. On Linux, they hit the Linux kernel instead, which sees a completely different syscall numbering scheme, causing a crash or silent corruption. Proton had worked around this for years using seccomp-bpf filters. Syscall User Dispatch (a Linux kernel feature since version 5.11, released 2021) provides a cleaner solution: it lets Wine tell the kernel to redirect those non-native syscalls back to userspace, where Wine can intercept and handle them correctly -- with no kernel call required to switch modes, just a write to memory. Games like Red Dead Redemption 2, Detroit: Become Human, and Arknights: Endfield that depended on this behavior now work in mainline Wine. The underlying bug report (Wine #48291) had been open since 2019. Wine 11.5 also adds C++ build system support and bundles ICU libraries (International Components for Unicode) for more consistent international text handling. It is a development build rather than a stable release, available through Wine's staging repositories.

Wine 11.6: DLL Load-Order Heuristics for Mod Support

Wine 11.6, released April 3, 2026, is a development build that adds DLL load-order heuristics designed to improve compatibility with game mods that ship as third-party DLLs. Previously, mods that dropped DLL files alongside a game executable could be ignored by Wine's resolution order, requiring manual overrides. The new heuristics detect these cases and load the mod DLLs automatically, without manual WINEDLLOVERRIDES configuration. The same change is expected to land in an upcoming Proton build. Wine 11.6 also begins reviving the experimental Android driver and continues incremental VBScript compatibility work.

Proton: What It Actually Is

Proton is not Wine with a different name. It is a complete gaming compatibility stack that takes Wine as its foundation and adds a substantial set of gaming-specific components:

• DXVK -- translates Direct3D 8, 9, 10, and 11 calls into Vulkan. This is the single biggest reason modern DirectX games run well on Linux. Without Vulkan translation, DirectX calls would have to go through OpenGL, which is dramatically slower for modern workloads.
• VKD3D-Proton -- translates Direct3D 12 calls into Vulkan. This is a separate project from the upstream VKD3D, with Valve's fork carrying additional performance work that upstream has not merged.
• esync, fsync, and NTSYNC -- Proton carried these synchronization improvements before they made it to Wine upstream. Proton-GE already has NTSYNC enabled; official Proton will gain it as it rebases on Wine 11.
• Steam runtime integration -- Proton runs inside a Pressure Vessel container (using bubblewrap) that provides a consistent set of system libraries regardless of what the host distribution ships. The runtime ships in three variants: Steam Runtime 1 "scout" (an Ubuntu 12.04-era library baseline, used by Proton 5.0 and earlier), Steam Runtime 2 "soldier" (a Debian 10-era baseline, used by Proton 5.13 through 7.0), and Steam Runtime 3 "sniper" (a Debian 11-era baseline, used by Proton 8.0 and later). When ProtonDB reports mention "sniper runtime" in a fix, this is what they mean. The containerization is why a game verified on SteamOS works identically on Arch, Fedora, and Ubuntu without modification.
• Per-game fixes -- the protonfixes system applies game-specific patches, environment variables, and workarounds automatically when you launch a game. You never see these; they just make things work.
• Steamworks integration -- multiplayer, achievements, cloud saves, and the Steam overlay all work through Proton in the same way they work on Windows.

"It isn't just Wine with a different name." — Adam Conway, XDA Developers, March 2026 (Wine 11 rewrites how Linux runs Windows games at the kernel level)

The other critical difference is that Proton manages Wine configuration automatically. When you install a game through Steam on Linux and hit Play, Proton initializes an isolated prefix for that game, applies any required protonfixes, sets the correct Windows version, and launches. There is nothing to configure. Wine without a front-end requires you to do all of that manually.

When to Use Each

The decision tree is more practical than technical. Here is how to think about it:

Use Proton when:

• You are running a Steam game. Proton is already there, already configured, and already has per-game fixes applied.
• You want the highest game compatibility without manual work. Proton's DXVK and VKD3D make it substantially better than standalone Wine for modern DirectX games.
• You want community compatibility data. ProtonDB tracks Proton compatibility, not standalone Wine. The knowledge base is far larger.
• You are running a non-Steam game through Lutris and want Proton's graphics translation stack -- you can set GE-Proton as the runner in Lutris, bringing DXVK and VKD3D to non-Steam games.

Use Wine directly when:

• You need to run non-gaming Windows software: productivity applications, legacy enterprise tools, utilities that have no Steam equivalent.
• You are doing software preservation work with very old 16-bit or 32-bit applications where Wine's broad compatibility coverage matters more than gaming-specific performance.
• You want manual control over the Wine environment: specific DLL overrides, custom prefix configuration, testing compatibility against vanilla Wine behavior.
• You are running a game that predates DirectX 8 and doesn't benefit from DXVK, where standalone Wine with the right configuration may be simpler to manage.

Performance vs. Windows: How Close Is It?

For most games, Proton performance is within a few percent of native Windows performance, and in measured comparisons it frequently exceeds it. DXVK's Vulkan translation path avoids several layers of CPU overhead that the Windows DirectX runtime carries, and on AMD hardware with open-source Mesa drivers the delta is sometimes meaningfully positive. Phoronix benchmark comparisons across 2024 and 2025 on titles like Cyberpunk 2077, Spider-Man Remastered, and The Witcher 3 showed Proton on Linux within 2--5% of Windows across GPU-bound scenarios, with occasional leads on AMD. The gap has narrowed to the point that GPU-bound workloads at typical gaming resolutions are indistinguishable in practice.

The main exception is shader compilation stutter. When you first run a game through Proton, DXVK has to compile Vulkan pipeline state objects from the DirectX shader bytecode it encounters at runtime. This happens on the fly the first time each shader is needed, producing hitches and micro-stutters during gameplay that disappear after the pipeline cache is warm. Subsequent sessions are smooth because DXVK caches the compiled shaders to disk. Steam pre-populates a pipeline cache for many titles through its shader pre-caching system, which is why downloading a game on Linux often involves a separate "Proton shader pre-caching" step -- that is DXVK building the cache before you ever launch.

The AMD versus Nvidia situation matters here. AMD's open-source Mesa drivers are a first-class target for DXVK and Wine, with excellent Vulkan support and no proprietary driver lag. Nvidia's proprietary driver also supports Vulkan well, but historically AMD has had fewer surprises on Linux. The open-source Nouveau driver for Nvidia is not suitable for gaming -- use the proprietary driver. If you are buying hardware specifically for Linux gaming, AMD graphics cards are the safer choice for driver stability and Vulkan coverage.

Side-by-Side Comparison

Anti-Cheat: The Remaining Hard Limit

Anti-cheat is the single biggest practical obstacle to Linux gaming in 2026, and the article owes you a direct treatment of it rather than leaving you to discover it the hard way. The short version: single-player games and many multiplayer titles run fine on Proton. A specific category of competitive multiplayer games -- the ones with kernel-level Windows-only anti-cheat -- do not run at all, and no amount of Wine or Proton configuration will change that.

What works

Both Easy Anti-Cheat (EAC) and BattlEye announced official Proton compatibility in 2021, allowing games using those systems to run on Linux when the game developer has opted in. VAC (Valve Anti-Cheat) is fully supported, which means Valve's own titles -- Counter-Strike 2, Dota 2, Team Fortress 2 -- work without caveats. The crowdsourced database Are We Anti-Cheat Yet (areweanticheatyet.com) tracks compatibility per-title and is more useful than ProtonDB for multiplayer games specifically.

What does not work

Several major competitive titles are blocked entirely on Linux and cannot be played through Proton regardless of version or configuration:

• Valorant -- uses Riot's Vanguard, a kernel-level anti-cheat that loads on Windows boot and requires TPM attestation. It explicitly blocks Linux environments. No Proton version works.
• Fortnite -- uses both EAC and BattlEye, but Epic has not opted in to Linux support for either, citing the "threat model" of a user-controlled kernel as too large a risk for a title of Fortnite's scale.
• Apex Legends -- had EAC support for Linux and ran on Steam Deck until October 2024, when EA and Respawn deliberately blocked Linux access, citing Linux as "a path for a variety of impactful exploits and cheats."
• Call of Duty (Warzone, Modern Warfare series) -- uses Ricochet, Activision's in-house kernel-level anti-cheat, which does not support Linux.
• Rainbow Six Siege, PUBG, Escape from Tarkov -- use BattlEye, but the respective developers have not opted in to Linux support even though BattlEye itself supports Proton.

If anti-cheat-protected multiplayer is your primary use case, check Are We Anti-Cheat Yet for the specific title before committing to Linux as your gaming platform. For single-player games, story-driven titles, and the many multiplayer games that have opted in, Proton is a non-issue.

GE-Proton: The Community Fork

GE-Proton, maintained by Thomas Crider (GloriousEggroll), is a fork of Proton that incorporates fixes for specific games faster than the official Proton release cycle allows. Where official Proton waits for validation before merging fixes, GE-Proton ships them as soon as they work, accepting that an occasional regression is worth the faster turnaround.

GE-Proton already has NTSYNC enabled, pulling from the Wine 11 development branch ahead of Valve's official rebase. It also carries media codec support for games that play video cutscenes in formats Valve strips from official Proton for licensing reasons.

You manage GE-Proton versions through ProtonUp-Qt, a graphical tool available in most gaming distributions. After installing a GE-Proton version, you can assign it per-game in Steam under Properties > Compatibility > Force the use of a specific Steam Play compatibility tool.

# Signs that GE-Proton might help a specific game:

# 1. Cutscene videos don't play (codec licensing issue in official Proton)
# 2. Game crashes that ProtonDB reports are fixed in GE builds
# 3. Audio issues specific to the Steam runtime version
# 4. Game predates a fix that's in GE but not yet in official stable

# Workflow: check ProtonDB for the specific game, read recent reports
# If reports mention GE-Proton by version, install that version via ProtonUp-Qt
# Set it per-game in Steam > Properties > Compatibility

Which Proton Version to Use

Steam ships with a bundled stable Proton version that is applied to all games unless you override it. You have three main choices for any given game:

• Proton Stable (the default) -- the tested, validated build that ships with Steam. Right for most games without any thought required.
• Proton Experimental -- a rolling build that gets fixes faster than the stable release cycle. Use this when a game has a known issue that is fixed in Experimental but not yet in Stable. ProtonDB reports will say so explicitly.
• GE-Proton -- the community fork discussed above, carrying fixes and codec support ahead of both official tracks. Use it when ProtonDB reports specifically recommend a GE version for your title.

The workflow for any specific game is: check ProtonDB, read recent reports sorted by most recent rather than most helpful. The "most helpful" sort surfaces reports that were upvoted when the game launched, potentially years ago, describing a version of the game that no longer exists. For any title that has received patches since release -- which is most games -- recent reports are the only reliable signal. Use whatever Proton version the community reports as working best. The ProtonDB badge on Steam store pages (Gold/Silver/Platinum/Borked) gives a quick at-a-glance view, but the individual reports explain the specific version and any required launch flags.

To set a version per-game in Steam: right-click the game → Properties → Compatibility → check "Force the use of a specific Steam Play compatibility tool" → select the version. This overrides whatever global default Steam is using without affecting other games.

Front-Ends: Lutris, Heroic, and Bottles

Running Wine directly from the terminal is viable for technical users, but most people running non-Steam games on Linux use a front-end that handles prefix management, dependency installation, and version switching. The three tools that cover the widest range of use cases are Lutris, Heroic Games Launcher, and Bottles -- and they solve meaningfully different problems.

Lutris

Lutris is a unified game launcher that aggregates your library from Steam, GOG, Epic Games Store, Battle.net, EA App, Ubisoft Connect, and other sources into a single interface. Its most important feature for Wine compatibility is its community-maintained install scripts: when a game is listed on Lutris, clicking Install often downloads a script that configures a Wine prefix, installs required runtime dependencies, handles launcher authentication, and sets correct environment variables -- all automatically.

Lutris supports multiple runners including Wine, GE-Proton, DOSBox, ScummVM, and RetroArch, making it a single tool for a wide range of gaming scenarios. It creates separate prefixes per game by default. For GOG, EA, and Ubisoft games that require their own launchers, Lutris install scripts handle the launcher setup inside a configured prefix.

Heroic Games Launcher

Heroic Games Launcher is an open-source client focused on Epic Games Store and GOG libraries. Unlike Lutris, which relies on community install scripts that can fall out of date, Heroic integrates directly with the Epic and GOG APIs, pulls your full library automatically, and handles installation and updates with the same friction level as Steam. It also supports Amazon Prime Gaming.

For runners, Heroic lets you select Wine, GE-Proton, or any custom Wine build per game, and it reads runners you have already installed through ProtonUp-Qt. Cloud save sync and ProtonDB integration (so you can check community compatibility data without leaving the launcher) are both built in. For someone whose library is primarily GOG or Epic, Heroic is the lowest-friction path to running those games on Linux, typically without needing to touch prefix settings manually.

The trade-off: Heroic does not cover Battle.net, EA App, or Ubisoft Connect, and it has no equivalent to Lutris install scripts for complex multi-launcher setups. If a game is exclusive to one of those stores or requires a launcher that Heroic does not support, Lutris is still necessary.

Bottles

Bottles takes a different conceptual approach. Rather than a game launcher, it is a Wine environment manager. You create "bottles" -- isolated Wine prefixes with their own configuration, runner version, and installed dependencies -- and then install multiple applications into the same bottle, or keep each application in its own bottle depending on your needs.

Bottles is particularly well suited for running non-gaming Windows software: a bottle for your office applications, a bottle for a legacy enterprise tool, a bottle for a specific utility. It provides built-in environment rollback (unlike Lutris, which requires manual backup), optional Bubblewrap sandboxing for additional isolation, and a cleaner interface for managing prefix-level settings like DLL overrides and Windows version.

For gaming, Bottles works, but Lutris and direct Steam/Proton are generally simpler. Where Bottles shines is the use case that Proton does not cover at all: running Windows productivity software, legacy business applications, or anything that isn't a game.

Going Deeper: Tools Most Guides Skip

The typical Linux gaming explainer tells you to install Proton, check ProtonDB, and try GE-Proton if something breaks. That covers maybe 80% of situations -- and if you are still in the early stages, the switching to Linux for gaming guide covers that foundation. The remaining 20% -- where a game runs but has wrong rendering, frame pacing issues, audio problems, or crashes that logs can explain -- requires knowing the layer underneath. This section covers the tools serious Linux gamers use but rarely see documented in one place.

Installing DXVK Into a Standalone Wine Prefix

When you run a non-Steam Windows game through plain Wine, you get Wine's built-in DirectX implementation (wined3d), which translates DirectX through OpenGL. This is substantially slower than DXVK's Vulkan path for any game using DirectX 9 through 11. Proton ships DXVK automatically; standalone Wine does not. Installing it manually is straightforward:

# Download DXVK release tarball from github.com/doitsujin/dxvk/releases
# e.g. dxvk-2.x.y.tar.gz -- extract it, then cd into the extracted folder
$ tar -xf dxvk-2.x.y.tar.gz && cd dxvk-2.x.y
$ export WINEPREFIX=~/.wine-game-x
$ cp x64/*.dll $WINEPREFIX/drive_c/windows/system32/
$ cp x32/*.dll $WINEPREFIX/drive_c/windows/syswow64/

# Open winecfg and add native DLL overrides for the translation DLLs
$ WINEPREFIX=~/.wine-game-x winecfg
# In the Libraries tab, add overrides for:
# d3d8, d3d9, d3d10core, d3d11, dxgi -- set each to "native, then builtin"

# Alternatively: winetricks handles this automatically
$ WINEPREFIX=~/.wine-game-x winetricks dxvk

# Verify DXVK is active -- you should see the DXVK version in the overlay
$ WINEPREFIX=~/.wine-game-x DXVK_HUD=version wine /path/to/game.exe

The winetricks dxvk verb is the simplest path -- it installs a pinned DXVK version bundled with your winetricks release and handles DLL override registration automatically. Note that the pinned version may trail the latest DXVK release by several months; if you are debugging a compatibility issue with a recently released game, downloading the current tarball from DXVK's GitHub and installing manually ensures you have the latest fixes. Older games that regressed in newer DXVK versions can benefit from specifying an older version the same way.

DLL Overrides: The Most Underused Troubleshooting Tool

Wine maintains a DLL resolution order: for any given DLL, it can use the native Windows version (dropped into the prefix by Winetricks or manual installation), Wine's own built-in reimplementation, or a combination. The override controls which takes priority. This is exposed through winecfg's Libraries tab, but the faster path for scripting or launch options is the WINEDLLOVERRIDES environment variable:

# Syntax: WINEDLLOVERRIDES="dll1=order;dll2=order"
# Orders: n = native, b = builtin, n,b = try native first then builtin

# Force DXVK's d3d11 instead of wined3d
$ WINEDLLOVERRIDES="d3d11=n;d3d10core=n;dxgi=n" wine game.exe

# Install a native vcrun (Visual C++ runtime) and force Wine to use it
$ WINEPREFIX=~/.wine-game winetricks vcrun2019
# vcrun2019 installs multiple DLLs; modern games also need vcruntime140_1
$ WINEDLLOVERRIDES="msvcp140=n;vcruntime140=n;vcruntime140_1=n" wine game.exe

# Common fix for games that need native dinput8 (controller/input issues)
$ WINEDLLOVERRIDES="dinput8=n,b" wine game.exe

# In Steam launch options (Proton), use the same syntax before %command%
# WINEDLLOVERRIDES="d3d11=n;dxgi=n" %command%

When a game crashes immediately, produces a black screen, or exhibits rendering artifacts, a DLL override is frequently the fix. The pattern is: identify which DLL the game is failing on (the debug log will tell you -- see below), install the native Windows version of that DLL with Winetricks if needed, and force Wine to use it with an override. The WineHQ AppDB entry for a specific application almost always documents which overrides are required.

MangoHud: Real-Time Performance Visibility

MangoHud is an open-source Vulkan and OpenGL overlay that displays FPS, frame times, CPU and GPU load, temperatures, VRAM usage, and more, rendered directly over your game. It is the standard performance monitoring tool for Linux gaming, equivalent in purpose to MSI Afterburner or RivaTuner on Windows -- and unlike those tools, it works natively with Proton and Wine without any special configuration.

# Install (package name varies by distro)
$ sudo apt install mangohud           # Debian/Ubuntu
$ sudo dnf install mangohud           # Fedora
$ sudo pacman -S mangohud lib32-mangohud  # Arch (include 32-bit for older games)

# Enable for a specific Steam game (add to Launch Options field)
# MANGOHUD=1 %command%

# Enable for a Wine game run from terminal
$ MANGOHUD=1 wine /path/to/game.exe

# Customize what the overlay shows (~/.config/MangoHud/MangoHud.conf)
# fps, frame_timing, cpu_load, gpu_load, vram, temps, frametime, etc.
# Toggle the overlay in-game with Shift+F12

MangoHud's frame time graph is especially useful for diagnosing shader stutter: you can see exactly when DXVK is compiling a pipeline state object because the frame time spikes sharply and then returns to baseline. Once the cache is warm, the graph flattens. If you see persistent frame time variance rather than isolated spikes, the bottleneck is something else -- CPU scheduling, memory bandwidth, or a GPU driver issue.

GameMode: CPU Governor Scheduling for Gaming

GameMode is a daemon from Feral Interactive (the studio that ports many Windows games to Linux) that automatically switches the CPU governor to performance mode, disables power-saving features that add scheduling latency, and boosts I/O priority for the game process tree while a game is running -- then reverts everything when the game exits. It costs nothing in terms of configuration. On CPU-bound workloads where the system is running a power-saving CPU governor (the default on many laptops and desktop distributions), GameMode can produce 5--15% FPS improvements by removing governor-induced scheduling latency between frames. On a desktop system with the CPU governor already pinned to performance, or in a GPU-bound game where the CPU is not the constraint, GameMode has no measurable effect. The gains are most reliable on laptops and systems with AMD or Intel processors running the default schedutil or powersave governor. For a broader look at system-level tuning specific to one distribution, the Fedora gaming optimization guide covers CPU governor configuration, kernel parameters, and GPU tuning in detail.

# Install
$ sudo apt install gamemode        # Debian/Ubuntu
$ sudo dnf install gamemode        # Fedora
$ sudo pacman -S gamemode          # Arch

# Wrap any game launch with gamemoderun
$ gamemoderun wine /path/to/game.exe

# Steam launch option: combines GameMode and MangoHud
# MANGOHUD=1 gamemoderun %command%

# Verify GameMode is active during a session
$ gamemoded -s

Debugging Wine and Proton Failures

When a game crashes or refuses to launch, the default behavior is silence. Both Wine and Proton have logging systems that expose exactly what is failing, but they are opt-in.

For Proton games through Steam, add PROTON_LOG=1 to Steam's launch options before %command%. This writes a log to ~/steam-<appid>.log in your home directory, where appid is the game's numeric Steam App ID (visible in the store URL). If you don't know the App ID, run ls ~/steam-*.log after a crash to find the file. The log includes the full Wine debug output, the Proton version in use, and the exit code. The most useful lines to search for are err: prefixed entries and fixme: entries for unimplemented API stubs that the game is hitting.

For standalone Wine, the WINEDEBUG environment variable controls the debug channel output:

# Log errors and fixme stubs to a file (quiet enough to be useful)
$ WINEDEBUG=err+all,fixme+all wine game.exe 2> wine-debug.log

# Log only a specific channel (e.g., d3d errors, loaders, file access)
$ WINEDEBUG=err+d3d wine game.exe
$ WINEDEBUG=err+module wine game.exe      # DLL load failures
$ WINEDEBUG=err+file wine game.exe        # missing file paths

# DXVK has its own logging, separate from Wine's WINEDEBUG
$ DXVK_LOG_LEVEL=info DXVK_LOG_PATH=/tmp/dxvk wine game.exe
# Writes app_d3d11.log, app_dxgi.log etc. to the specified directory

# For Proton via Steam (add to Launch Options before %command%)
# PROTON_LOG=1 %command%
# Log lands at ~/steam-APPID.log (replace APPID with the game's Steam ID)

Key Environment Variables for Proton and Wine

Both Wine and Proton are controlled heavily through environment variables. These are set either in the terminal before launching, in Steam's launch options field (before %command%), or in Lutris's environment variable configuration for a game. The most practically useful ones:

# Force Proton to use wined3d instead of DXVK (for games where DXVK breaks things)
# PROTON_USE_WINED3D=1 %command%

# Disable esync (when hitting file descriptor limits, or for testing)
# PROTON_NO_ESYNC=1 %command%

# Disable NTSYNC and fall back to fsync (for testing sync behavior)
# PROTON_NO_NTSYNC=1 %command%

# Override the Windows version Wine reports (default is Windows 10)
$ WINEPREFIX=~/.wine-game WINEARCH=win64 winecfg
# Set via the Applications tab in winecfg per-application, or globally

# DXVK built-in HUD: show GPU name, driver, FPS, pipeline state compile count
# DXVK_HUD=devinfo,fps,pipelines %command%
# DXVK_HUD=full  (everything)

# Force DXVK to use a specific GPU (for multi-GPU laptops)
# DXVK_FILTER_DEVICE_NAME="AMD" %command%

# Enable DXVK's Vulkan validation layers (heavy -- for debugging only)
# DXVK_DEBUG=validation %command%

The DXVK_HUD variable deserves special mention: it is a zero-overhead diagnostic that runs inside the DXVK translation layer itself and reports the pipeline compile count in real time. When you see that number climbing during gameplay, you are watching shader compilation stutter in progress. Once it plateaus and stops climbing in a session, the first-run stutter for that area of the game map is done.

Winetricks: Installing Windows Dependencies

Regardless of whether you use Wine or Proton, you will eventually encounter a game or application that requires specific Windows runtime components that are not provided by the compatibility layer itself. Winetricks is the tool for this: it is a script-based "package manager" that installs common Windows DLLs, fonts, runtimes, and frameworks into a Wine prefix.

# Visual C++ redistributables (most modern games need these)
$ WINEPREFIX=~/.wine-game winetricks vcrun2019

# .NET Framework (many older games and some launchers)
$ WINEPREFIX=~/.wine-game winetricks dotnet48

# DirectX components
$ WINEPREFIX=~/.wine-game winetricks d3dx11

# Core fonts (required by many applications)
$ WINEPREFIX=~/.wine-game winetricks corefonts

# Multiple packages in one command
$ WINEPREFIX=~/.wine-game winetricks vcrun2019 corefonts d3dx11

# Run the graphical interface
$ WINEPREFIX=~/.wine-game winetricks --gui

When using Proton through Steam, you generally do not run Winetricks directly -- Proton's protonfixes system handles most of this automatically for listed games. For non-Steam games run through Lutris, Winetricks is accessible through Lutris's interface: the wine glass icon at the bottom of the window opens the Winetricks prefix menu, where you can install components without dropping to a terminal.

How to Run a Non-Steam Windows Game with Wine

Step 1: Install Wine

On Debian and Ubuntu-based systems, the version of Wine in the default repositories is typically outdated. Use the official WineHQ repositories for a current build. Wine Staging is the development branch that includes experimental patches not yet merged into stable Wine -- it generally performs better for gaming and is recommended over winehq-stable for that purpose. The WineHQ wiki at wiki.winehq.org/Download has per-distribution instructions. On Fedora and Arch, the Wine packages in the official repositories are more current and acceptable to use directly:

# Debian/Ubuntu: add WineHQ repo first (see wiki.winehq.org/Debian or /Ubuntu)
# then install staging (preferred for games) or stable
$ sudo apt install --install-recommends winehq-staging

# Fedora
$ sudo dnf install wine

# Arch Linux
$ sudo pacman -S wine wine-mono wine-gecko

Step 2: Create an isolated Wine prefix

Set the WINEPREFIX environment variable to a dedicated directory for your game before running anything. For example: export WINEPREFIX=~/.wine-mygame && wineboot. This initializes a fresh isolated Windows environment for that game only, preventing interference with other Wine installations.

Step 3: Install required Windows components with Winetricks

Use Winetricks to install any Windows runtime dependencies the game requires inside your prefix. Common needs include Visual C++ redistributables (vcrun2019), DirectX components, and .NET Framework. Example: WINEPREFIX=~/.wine-mygame winetricks vcrun2019 d3dx11.

Step 4: Run the game and test

Launch the game with your prefix set. For example: WINEPREFIX=~/.wine-mygame wine /path/to/game.exe. Check ProtonDB for any game-specific launch flags or fixes. If the game performs poorly, consider switching to Lutris and using GE-Proton as the runner, which brings Proton's full graphics translation stack to non-Steam games.

Frequently Asked Questions

What is the difference between Proton and Wine?

Wine is the foundational compatibility layer that translates Windows API calls into POSIX system calls, allowing Windows software to run on Linux. Proton is a gaming-focused stack built on top of Wine by Valve that adds DXVK (Direct3D 9/10/11 to Vulkan translation), VKD3D-Proton (Direct3D 12 to Vulkan), synchronization optimizations, Steam integration, and per-game configuration fixes. Proton is not just Wine with a different name: the gaming-specific additions make a meaningful difference in performance and compatibility for modern titles.

When should I use Wine instead of Proton?

Wine is the right choice when you need to run non-gaming Windows software (productivity tools, legacy applications, utilities), when you are working outside of Steam and want direct control over your Wine prefix, or when you need to run software that does not benefit from Proton's gaming-specific layer. Wine is also preferred for preservation work with very old 16-bit or 32-bit Windows software, especially with Wine 11's completed WoW64 architecture. For Steam games, Proton is almost always the better choice.

What is NTSYNC and why does it matter for Linux gaming?

NTSYNC is a kernel driver merged into Linux 6.14 (released March 24, 2025) that handles Windows NT-style synchronization primitives at the kernel level rather than approximating them in userspace. Prior to NTSYNC, Wine and Proton used workarounds called esync and fsync. NTSYNC is semantically correct in ways those workarounds were not, and it shipped in Wine 11.0 (January 2026). Developer benchmarks showed Dirt 3 going from 110.6 to 860.7 FPS (678%), Tiny Tina's Wonderlands from 130 to 360 FPS, Call of Juarez from 99.8 to 224.1 FPS, and Resident Evil 2 from 26 to 77 FPS -- all measured against vanilla Wine with no sync workarounds. For users already on Proton with fsync enabled, real-world gains are more modest but measurably real, especially in games with heavy multi-threaded workloads.

What is a Wine prefix and why does it matter?

A Wine prefix is an isolated directory containing a simulated Windows C: drive, registry, and application data. It is where Wine and Proton store everything a Windows program would store on its host system. Using separate prefixes for different games or applications prevents them from interfering with each other's DLL overrides, registry settings, and installed components. Steam and Proton manage prefixes automatically. When using standalone Wine, you set the prefix with the WINEPREFIX environment variable.

What did Wine 11.5 fix and do I need to upgrade my kernel for it?

Wine 11.5 (released March 20, 2026) introduced Syscall User Dispatch support in NTDLL, closing Wine bug #48291 that had been open since 2019. The problem was that some Windows software -- particularly certain DRM systems and anti-cheat implementations -- bypasses the DLL layer and issues raw x86_64 SYSCALL instructions. On real Windows, those hit the NT kernel. On Linux, they hit the Linux kernel, which uses a completely different syscall numbering scheme, causing crashes. Syscall User Dispatch, a Linux kernel feature since version 5.11 (released 2021), lets Wine redirect those calls back to userspace to handle correctly. Unlike NTSYNC, which requires Linux kernel 6.14, Syscall User Dispatch has been available since 5.11, meaning users on modern distributions have the required kernel support without any upgrade. Games fixed include Red Dead Redemption 2, Detroit: Become Human, and Arknights: Endfield. Wine 11.5 is a development release; install from Wine staging repositories to use it now.

When should I use Heroic Games Launcher instead of Lutris?

Heroic Games Launcher is the stronger choice for GOG and Epic Games Store libraries. It presents a clean, account-linked interface that installs and launches games with minimal configuration, handles Wine and Proton runner selection, and syncs cloud saves. For GOG specifically, Heroic is generally simpler and more consistently maintained than Lutris. Lutris remains the better option for complex setups requiring its community install scripts -- Battle.net, the EA App, Ubisoft Connect, and similar launchers that need multi-step prefix configuration to function. Both tools can use GE-Proton as a runner. If a game does not work in Heroic and you need fine-grained control over the Wine environment, Lutris gives you that.

What is Steam Play and is it the same as Proton?

Steam Play is Valve's umbrella program for running non-Linux games on Linux through Steam. It has two modes: native Linux builds (which Steam Play has always handled) and Windows games run through a compatibility tool. When people say "Steam Play" in the context of Linux gaming, they almost always mean the second mode -- which uses Proton. "Enable Steam Play for all titles" in Steam Settings → Steam Play is the setting that tells Steam to use Proton even for games that are not whitelisted by Valve. Proton is the actual compatibility tool; Steam Play is the Steam feature that invokes it. They are not the same thing, but the terms are often used interchangeably in community discussions.

What is CrossOver and how does it relate to Wine?

CrossOver is a commercial product made by CodeWeavers that is built directly on Wine. It provides a polished graphical interface for installing and running Windows software, a curated list of supported applications with compatibility ratings, and professional support. CodeWeavers engineers contribute heavily to Wine upstream -- Zeb Figura, who built esync, fsync, and NTSYNC, is a CodeWeavers employee. CrossOver costs money (around $74 for a perpetual license), but it funds the Wine development work that benefits everyone. If you need to run business software like Microsoft Office reliably and do not want to manage Wine configurations yourself, CrossOver is worth considering. For gaming, standalone Wine with Proton or GE-Proton is generally more capable for recent titles.

Does Wine work on macOS, and what about Proton on Mac?

Wine runs on macOS and has for many years -- it is the foundation under CrossOver for Mac. The macOS situation is complicated by Apple's transition to Apple Silicon (ARM), because most Windows games are x86-64 and running them on an ARM Mac requires instruction set translation on top of the Wine API translation. Wine supports this through its built-in ARM-to-x86 emulation layer, though performance varies significantly by title. Valve's official Proton is Linux-only and does not ship a macOS build. For Mac users wanting to run Windows games, CrossOver is the primary supported option; Game Porting Toolkit (Apple's own compatibility layer) handles some titles natively on Apple Silicon. Neither solution covers as many games as Proton does on Linux.

Does Wine run every Windows application?

No. Wine's compatibility is broad but not complete. The WineHQ Application Database (AppDB) at appdb.winehq.org tracks community-tested ratings: Platinum (works out of the box), Gold (works with minor tweaks), Silver (works with workarounds), Bronze (installs but has significant issues), and Garbage (does not work). The AppDB is less actively maintained than ProtonDB for games, but it is the primary reference for non-gaming Windows software. Software that makes heavy use of undocumented Windows internals, kernel-mode drivers, or anti-cheat systems (see the anti-cheat section above) is least likely to work. Software that uses standard Win32 APIs -- productivity tools, utilities, older games -- generally fares well. When in doubt, search the AppDB and recent forum posts before investing time in configuration.

Sources and Further Reading

The factual claims in this article are drawn from primary and authoritative secondary sources. Version-specific technical details are sourced directly from official release announcements and kernel documentation where available.

• XDA Developers, "Wine 11.6 just made modding Windows games on Linux easier, and Proton could be next" (Adam Conway, April 2026) -- xda-developers.com
• WineHQ release announcement, Wine 11.0 -- winehq.org/news/2026011301
• Phoronix, "Wine 11.5 Release Is Big: Syscall User Dispatch Feature Supported On Linux" (Michael Larabel, March 20, 2026) -- phoronix.com
• Phoronix, "Wine 11.0 Planned For Release Tomorrow With NTSync Support, Better WoW64" (Michael Larabel, January 12, 2026) -- phoronix.com
• XDA Developers, "Wine 11 rewrites how Linux runs Windows games at the kernel level, and the speed gains are massive" (Adam Conway, March 2026) -- xda-developers.com
• XDA Developers, "Wine has been translating Windows games to Linux since 1993, but Proton is what made it effortless" (2026) -- xda-developers.com
• OMG! Ubuntu, "Wine 11.0 Brings Ntsync Support, Complete WoW64 + Other Changes" (Joey Sneddon, January 13, 2026) -- omgubuntu.co.uk
• GamingOnLinux, "Wine 11.5 released with support for Syscall User Dispatch on Linux" (March 2026) -- gamingonlinux.com
• Linuxiac, "Wine 11.0 Brings Fully Supported WoW64 Mode and Linux Kernel NTSync Support" (Bobby Borisov, January 13, 2026) -- linuxiac.com
• 9to5Linux, "Linux Kernel 6.14 Officially Released" (Marcus Nestor, March 24, 2025) -- 9to5linux.com
• Valve Software -- Proton GitHub repository: github.com/ValveSoftware/Proton
• WineHQ -- Wine application database and documentation: winehq.org
• Are We Anti-Cheat Yet -- crowdsourced anti-cheat compatibility database: areweanticheatyet.com
• WineHQ AppDB -- Wine application database: appdb.winehq.org
• ProtonDB -- community game compatibility reports: protondb.com