Wine 11.15 arrived on Saturday August 8, slightly off the project's usual Friday cadence, with 41 bug fixes and two changes worth reading twice. The first is ARM64EC build support through MinGW, which matters to anyone assembling Windows on ARM binaries with an open toolchain. The second is a Wayland fix for washed out colours caused by a double sRGB conversion, a class of defect that is easy to live with and hard to notice you are living with. Underneath all that sits bug 4811, opened in March 2006 against MSXML3, finally closed. We went through what actually changed.
The short answer
Wine 11.15 shipped on Saturday August 8, off the project's usual Friday rhythm, with 41 bug fixes. The headline additions are ARM64EC build support through MinGW, more key derivation algorithms in BCrypt, extra format conversions in WindowsCodecs, and in process NTLM handling in msv1_0. Two Wayland corrections land: washed out colours from a double sRGB conversion, and 4:3 fullscreen applications whose content was offset. Bug 4811, an MSXML3 defect in XMLDOMDocument filed in March 2006, is finally closed. This is a development release, not the stable branch.
Most Wine releases are a list you skim. This one has a line in it that is genuinely funny in a way only long lived software can manage: a bug report opened in March 2006 got closed on Saturday. Bug 4811, an MSXML3 defect in the XMLDOMDocument area, spent twenty years in the tracker being correct.
The part that changes what you can build
The most consequential entry is ARM64EC build support through MinGW. ARM64EC is Microsoft's mixed mode ABI for Windows on ARM, and its whole purpose is to let native ARM64 code and emulated x64 code live in the same process. That is what makes incremental porting possible: you compile the modules that matter to native ARM64, leave the plugin nobody has sources for running under emulation, and ship something that works before the entire dependency graph has been ported.
Producing binaries for that ABI has largely meant using Microsoft's toolchain. Bringing it into MinGW moves it into the open cross compilation path, which is useful to Wine internally on ARM hosts and useful to anyone who builds Windows targets from a Linux machine and would rather not add a Windows builder to the pipeline for one ABI.
Two Wayland fixes that most people will feel before they notice
The colour fix is the interesting one. Wine 11.15 corrects washed out colours caused by a double sRGB conversion, which happens when content that is already sRGB encoded gets treated as linear and converted again on its way to the display. The visible result is not a broken image, it is a slightly lifted, slightly flat one. Midtones rise, contrast falls, and the whole thing reads as milky.
That failure mode is durable precisely because it is mild. Nobody opens a bug titled "the greys are wrong by a small amount", so it persists until someone chases the pipeline end to end. The second Wayland fix is more obvious in use: 4:3 fullscreen applications had their content offset within the output instead of sitting where it should, which is the kind of thing you notice immediately and then work around by not going fullscreen.
Both matter more than a typical single application fix because they affect the display path rather than one program. Anyone running Wine on a Wayland session is in scope.
The rest of the batch
Three smaller additions round it out. BCrypt gained more key derivation function algorithms, extending the set of cryptographic primitives Wine's implementation of the Windows API can satisfy rather than returning an unsupported algorithm error. WindowsCodecs picked up additional format conversions, so the imaging component can move between more pixel formats without the calling application having to bridge the gap, which is a recurring cause of blank or wrong looking images in software that assumes the platform will handle it. And msv1_0 now handles in process NTLM authentication with a fallback, improving behaviour for applications that expect to authenticate against the local machine the way they would on Windows.
The application specific fixes follow the usual distribution. Games take a share, and so do the long tail of business applications that keep Wine relevant in places nobody writes about: WordPerfect 7 and QuickBooks 2009 both appear in this release.
What to do with it
Treat 11.15 as what it is. Development releases come out roughly every fortnight and exist so that problems surface before the annual stable branch, which means running one in production is a choice to be an early tester. If Wine underpins something people rely on, stay where you are.
If you are tracking a specific defect, though, this is a large batch and the fastest test is your own application. And if you run Wine under Wayland at all, the colour and fullscreen corrections are a reason to try it that has nothing to do with any single program. The twenty year old MSXML3 fix will not change anybody's day, but it is a reminder that Wine's tracker is less a backlog than an archive of Windows behaviour, and that entries in it do not expire just because the calendar moved.
Sources and further reading
- Wine 11.15 Released With Wayland Fixes, Fix For A 20 Year Old MSXML3 Bug, Phoronix, August 8, 2026
- Wine 11.15 release notes, WineHQ GitLab
- WineHQ project home and downloads
- Wine Bugzilla, bug 4811
Frequently asked questions
What is ARM64EC and why does MinGW support for it matter?
ARM64EC is Microsoft's application binary interface for Windows on ARM that lets ARM64 native code and emulated x64 code coexist inside a single process. The practical use is incremental migration: a large application can compile its hot modules to native ARM64 while leaving plugins, third party libraries and anything without ARM sources running under emulation, all in the same address space, instead of demanding that the entire dependency tree port at once. Until now, producing ARM64EC binaries in practice meant Microsoft's toolchain. Wine 11.15 adding ARM64EC build support through MinGW puts that target inside the open toolchain, which matters in two directions. It gives Wine itself a cleaner path to building the mixed mode modules it needs on ARM hosts, and it gives anyone who cross compiles Windows binaries from Linux a route to the same ABI without a Windows build machine in the loop.
What was the washed out colour problem on Wayland?
A double sRGB conversion, which is the colour management equivalent of applying the same correction twice. Pixel values in most Windows applications are already encoded in sRGB, so if the compositing path treats them as linear and converts them to sRGB again on the way to the display, everything comes out lighter and flatter than it should be. Midtones lift, contrast drops, and the result reads as slightly milky rather than obviously broken, which is exactly why this kind of bug survives for a while. Nobody files a report saying the greys are two percent wrong. Wine 11.15 fixes it, alongside a second Wayland correction where 4:3 fullscreen applications had their content offset within the output rather than sitting where it belonged. Both are the sort of thing you only appreciate after the fix, when the same application stops looking subtly off.
How does a bug stay open for twenty years in an active project?
By being real, reproducible, and never quite anyone's priority. Bug 4811 was filed in March 2006 against MSXML3, Microsoft's XML services component, in the XMLDOMDocument area. MSXML3 is the kind of dependency that shows up under older business software and installers rather than under anything with an active user community, so the population hitting the defect was small, technical and mostly able to work around it. Wine's bug tracker holds a long tail of exactly this shape: precisely characterised defects in components whose remaining users number in the dozens. They get closed when someone happens to be working nearby in the code, which is what appears to have happened here. The reason it is worth mentioning is not the fix itself but what it says about the tail: twenty year old reports in Wine are frequently still accurate, because the Windows behaviour they describe never changed either.
Is 11.15 a release I should deploy, or wait for the stable branch?
Wine 11.15 is a development release, published roughly every two weeks on the road to the next stable series, so the usual advice applies. If you run Wine as part of a workflow that people depend on, stay on the stable branch and let the development releases shake out. If you are chasing a specific fix in this batch, and 41 of them landed including work on WordPerfect 7 and QuickBooks 2009 alongside various games, then testing 11.15 against your own application is the fastest way to find out whether your issue is among them. The two Wayland corrections are the ones most likely to affect a general desktop rather than one application, so anyone running Wine on a Wayland session has a broader reason to try it than usual.
What else changed in this release beyond the headline items?
Three things worth naming. BCrypt gained additional key derivation function algorithms, which extends the set of cryptographic primitives applications can request from Wine's implementation of the Windows cryptography API rather than failing on an unsupported algorithm identifier. WindowsCodecs picked up more format conversions, meaning the imaging component can move between more pixel formats without an application having to handle the gap itself, a common source of blank or corrupted images in applications that assume the platform will convert for them. And msv1_0 now handles in process NTLM authentication with a fallback path, which improves compatibility for software that expects to authenticate against the local machine the way it would on Windows. None of these is dramatic on its own. Together they are the usual Wine pattern of removing reasons for an application to give up.