Wine 11.20 lands with ARM64EC relay debugging and a stack overflow fix
Wine's latest bi-weekly development release is out, bringing ARM64EC relay debugging, tighter XML validation, a reshuffled CD-ROM subsystem, and a memory-safety fix that closes an actual buffer overflow in the Windows command interpreter.
Wine runs Windows apps on Linux, FreeBSD, and macOS without spinning up a virtual machine or emulating a CPU. It re-implements the Windows API in user space, translating each call into a native operation. There's no Microsoft binary bundled. Everything, including the undocumented quirks that some software depends on, is rewritten from scratch.
Stable releases like Wine 11.0 come out roughly once a year and bundle thousands of changes. Development releases like 11.20 roll out every two weeks on Fridays as rolling snapshots heading toward the next stable build. This 11.x series is expected to culminate in Wine 12.0 sometime in early 2027.
That's worth remembering before you get excited about the feature list. These are betas. They can break something that worked last week, and they're aimed at people comfortable building from source or trusting a distro package.
What actually changed
Three items show up on top.
Relay debugging for ARM64EC is the one developers will care about most. Relay logging, that's the WINEDEBUG=+relay mode, records every function call in and out of every DLL, giving a complete trace of an app's API activity. ARM64EC is Microsoft's hybrid ABI for Windows 11 on ARM, where native ARM64 code shares a process with x64 code that runs under the OS's built-in emulation.
Setting up that trace was fiddly because the process straddles two instruction sets. So Wine now delays relay setup until after the ARM64EC module initializes and exposes relay descriptors through the load-config extension. The payoff is that you can finally trace calls across the ARM/x64 boundary. That matters for getting the growing pile of ARM64EC-targeted Windows apps working on aarch64 Linux, including Apple Silicon.
XML validation got a broad refresh in msxml. Microsoft's libraries were more forgiving than Wine's reimplementations in ways that broke real software, most notably the Office 2013 Click-to-Run installer and a handful of QuickBooks products, which fail outright with Wine's built-in msxml6.
The work, largely by Nikolay Sivov with related fixes from Hans Leidekker and others, now validates root element names against the DTD, handles undeclared elements and undefined attributes, and reports multiple errors at once instead of stopping at the first. A smaller fix that accepts "unicode" as an alias for UTF-16 in save() directly clears bug #60424. That's the concrete, user-facing win, since so many installers lean on Microsoft's lenient handling of that encoding label.
The third headline change is structural: CD-ROM support has moved out of ntdll and into the Mount Manager.
Historically, ntdll opened Unix device files directly and issued raw ioctls for things like ejecting a disc or reading media type. That logic now lives entirely in the Mount Manager (mountmgr), and ntdll no longer opens those devices itself. Elizabeth Figura led the rework, part of a larger overhaul of how Wine lays out device handling in the ntdll address space.
It's arguably more faithful to how real Windows NT works, where mountmgr is the single coordinator for drive and media management. It also removes some duplicated, fragile code. The practical upside shows up in apps that query optical media or copy driver files to c:\windows\syswow64\drivers, a real bug for Battlefield 1942, per issue #60466.
The security-relevant one
Not every change is a feature. One bug fixed this cycle is a genuine memory-safety issue.
Bug #60383 is a stack buffer overflow in cmd's search_command. When the interpreter is invoked with a quoted /c argument whose command line exceeds the 260-character MAX_PATH limit, an unbounded copy into a fixed stack buffer could corrupt adjacent memory. Stack overflows are among the oldest serious vulnerability classes, since careful exploitation can hand an attacker control of program execution.
In Wine's case, the blast radius is limited to the local user running the interpreter under Wine, not the host OS. Still, it's a real exploit surface being closed. No CVE has been publicly assigned, so treat this as an internal fix with security relevance rather than a named vulnerability.
Eric Pouech's broader cmd rework in this same release, rebuilding built-in commands like FOR, SET /A, DEL, and MKLINK around a single shared word iterator, pairs directly with the overflow fix and tightens the interpreter as a whole.
The broader 11.x cycle
Wine 11.0, stable, landed in January 2026 after roughly a year of work, around 6,300 changes and 600-plus bug fixes. Its two marquee features were NTSYNC support, which exposes a kernel-mode device so Wine can model Windows synchronization objects directly in the host kernel, and completion of the new WoW64 architecture for mixing 32- and 64-bit apps in one instance.
The 11.x series has spent its time incrementally extending that base: ARM and ARM64EC support, Vulkan and Wayland/EGL graphics improvements, VA-API hardware decoding, DNS caching, and more kernel implementation. Community forks like wine-staging and Kron4ek's Wine-Builds typically package new releases within hours.
For gamers, the downstream path runs through Valve's Proton. Once Valve rebases Proton on Wine 11.x, features like NTSYNC roll out to SteamOS and Linux by default, potentially smoothing out large catalogs of older, stutter-prone games with nothing for users to install. It's a lot of low-level plumbing that only pays off if a given game actually hits it.
That's the honest framing: most of what Wine 11.20 does is foundation. The overflow fix is the part you should notice today.
How to grab it
Head here to download the source tarball. The full release notes with the commit log are available here.
