Discussion

Wine 11 rewrites how Linux runs Windows games at the kernel level, and the speed gains are massive

dinkblam: it seems if you want the same on macOS, this is the place to contribute:https://github.com/Alien4042x/Wine-NTsync-Userspace-macOS-ba...

ticulatedspline: Wine might be oddly self-defeating. Broad game support on Linux increases the viability of Linux as a desktop, which increases market share, which may result in developers creating Linux ports as a 1st class concern, which don't need Wine to run.

brightball: If any Wine devs are reading this, I'd love to see a talk on this topic at the 2026 Carolina Code Conference. Call for Speakers is open until March 31st.

tombert: Wine is a project that I've grown a near-infinite level of respect for.I don't know for sure, but I suspect that a lot of the work for Wine is boring and thankless. Digging through and trying to get exact parity with both the documented and undocumented behavior of Windows for the past 30 years doesn't sound fun, but it's finding every little weird edge case that makes Wine a viable product.The fact that Wine runs a lot of games better than Windows now (especially older games) shows a very strong attention to detail and a high tolerance for pain. I commend them for it.

hu3: > Dirt 3 went from 110.6 FPS to 860.7 FPS> Resident Evil 2 jumped from 26 FPS to 77 FPS> Call of Juarez went from 99.8 FPS to 224.1 FPS> Tiny Tina's Wonderlands saw gains from 130 FPS to 360 FPSAmazing. I don't understand the low level details on how such a massive speed gain was ripe for the picking but I welcome!I guess thanks Valve for pouring money into Proton.

adelmotsjr: Reading these posts always make me feel like an imposter. People are dealing with such low level things, while i'm outta here building simple CRUDs.

eurg: All good. I tell people how to add another mailbox to their Outlook, "click here, now there". Not glorious. Necessary anyways.

freediddy: i would love to know how much of these gains are due to help from AI. i have no problem with AI usage at all in coding but i would love to know if the dramatic gains are because of insights from ai usage.

krastanov: Wine's APIs are more stable than Linux's APIs, so it seems more plausible to me that Wine will become the first class target itself.

TehCorwiz: I wouldn't be surprised if Wine eventually becomes more stable than Windows.

carlos_rpn: It feels like it won't be long before Microsoft starts helping with that (by making Windows less stable, not improving Wine).

watashiato: Before anyone gets too excited about ntsync, the performance gains are (with few exceptions) mild, usually in the lower single percentage range. These extreme gains are the result of benching against vanilla wine without fsync, anyone playing demanding games on linux would have been doing so using fsync. This is mentioned in the article but treated like a side note. I've been running benchmarks between both and while the performance increase is real, please temper your expectations. A few titles might also run slightly worse.

akdev1l: >These extreme gains are the result of benching against vanilla without fsync, which is what anyone gaming on linux usesNot for anyone using a kernel without these patches. Which would be most people.

bmenrigh: Those benchmark numbers are slightly misleading, as they are a comparison of Wine+ntsync against Wine+nothing. There has been a somewhat fast "fsync" library built around Linux's futex and the gains over Wine+fsync are modest (just a few % in most cases).That said, Wine+ntysc is still a win, just not a 8x improvement like the Dirt 3 benchmark suggests.(And it case it's not clear, ntsync is https://docs.kernel.org/userspace-api/ntsync.html, which is a driver for Linux that offers syncronization primitives (mutex, semaphore, events) that more closely match the semantics of the Windows primitives. It's easier to do a direct implementation in Wine to supportcode compiled for Windows that expects to be talking to an NT kernel.)

Night_Thastus: I'll be very interested to see how this plays out with final 3rd-party benchmarks.Now if we can just get some decent Nvidia drivers......

foresto: Most people? What mainstream Linux distros ship without fsync or esync support?

orbital-decay: Unlikely. Games need a stable ABI and Win32 is the only stable ABI on Linux.

akdev1l: Proprietary software needs a stable ABI. Not games.DOOM runs on any Linux system since forever because we had access to the source. You can build it for Linux 2.6 and it’ll probably still work today.Sadly most games are proprietary

2OEH8eoCRo0: It's interesting when old Windows games run better in Wine than in actual Windows 10/11.

inetknght: It's even more interesting when the latest Windows games run better in Wine than in actual Windows 10/11.

porphyra: Wine actually does run some ancient Windows games better than Windows 11 itself.

zerr: The grass is always greener on the other side - many low-level programmers feel like an imposter when it comes to high-level systems such as CRUD apps.

irishcoffee: They don't. The "simplicity" of using a "high-level" framework for someone who bit-shifts for a living is almost comical.

chistev: Really?

keyringlight: What I wonder about is if MS wants to keep people on windows, what methods they can use to do that. For simple desktop stuff I don't think they have many options to lock in other developers (and their audiences) to windows unless they want do so themselves (putting aside web based or not PC-desktop).Bleeding edge gaming and multiplayer anti-cheat is one area where I think having a big company owning the OS probably helps them stay ahead, as that structure probably lets them work with hardware designers to get the capabilities in use (i.e. in new versions of DirectX) and available to software developers first. There's generally a lag in adoption for new features within Vulkan and then usage downstream in wine/proton to get compatibility parity with windows, then the games themselves being able to run feature/performance parity. It'd be interesting to see what cooperation would be needed to have the linux gaming stack equal at the point new features are released, and with the least amount of manual hacks or command line tweaking required for the users. As discussed a few weeks back, tough anti-cheat for linux seems like a paradox with the current methods.

dgunay: You can probably learn to do these things too with enough determination, but don't sell yourself short. Some CRUD apps can get deceptively complicated. Businesses have a way of coming up with just the right requirements to completely invalidate your architecture if you don't know what you're doing.

akdev1l: Well I can tell you that if it didn’t make it upstream Fedora didn’t ship it.It looks there was a copr for a custom kernel-fsync and projects like Bazzite or Nobara are adding patches.From my understanding the fsync patches were never upstreamed.

LtWorf: People who keep parroting this clearly have no experience of gaming on linux.

bombcar: I know literal kernel developers who can handle drivers and race conditions any day of the week who can't wrap their mind around Outlook, let alone GUI updates.

anal_reactor: Yes, Wine is truly a miracle. Once full support for Office is achieved, we should expect huge uptick in Linux adoption.

Teknoman117: As someone who works on systems at this level, believe me, it’s a learnable skill. And at least an intellectually valuable one I think too. Even if you never really need the knowledge for the things you do, there’s a nice feeling that comes from seeing something done at a high level and understanding how that makes its way down into the system and why those design choices were made.If I were more money motivated I’d probably be building CRUD apps too. I just like weird puzzles XD.

hungryhobbit: But does anyone care about MacOS? ;)I mean, I know Mac has had some great games (eg. I spent so much time on school Macs playing that Bolo tank game) ... but they have probably <1% of the number of games Windows has. I'd expect a simiilar percentage of devs to be interested in Mace (or whatever you call Mac Wine).

johnnyanmac: [delayed]

foresto: The common gaming-focused Wine&#x2F;Proton builds can also use esync (eventfd-based synchronization). IIRC, it doesn't need a patched kernel.The point being that these massive speed gains will probably not be seen by most people as you suggest, because most Linux gamers already have access to either esync or fsync.

akdev1l: Maybe you are right about esync but anyway I would also gather a lot of people don’t have that either. At least personally I don’t bother with custom proton builds or whatever so if Valve didn’t enable that on their build then I don’t have it.

foresto: > if Valve didn’t enable that on their build then I don’t have it.Proton is Valve's build. It supports both fsync and esync, the latter of which does not require a kernel patch. If you're gaming on Linux with Steam, you're probably already using it.https:&#x2F;&#x2F;github.com&#x2F;ValveSoftware&#x2F;Proton&#x2F;?tab=readme-ov-file#...

creesch: > There has been a somewhat fast "fsync" library built around Linux's futexThe article actually goes into that in quite a bit of detail about that.

bmenrigh: Yeah but to the commenter I was replying to, I don't think it was clear that detail was relevant to the benchmark numbers they were quoting.

dangoodmanUT: I had to close 3 ads before even half my screen was the articleAnd then it never was more than half…

zem: I work on compilers, and have bounced several times off trying to write my own full stack crud app for a personal project (tried doing it in rails, phoenix and django at various times). I'm finally getting somewhere with claude's help, but it really is its own set of skills - easy to get started with but hard to do well.

akdev1l: People always say this to shit on glibc meanwhile those guys bend over backwards to provide strong API compatibilities. It rubs me off the wrong way.What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.Such application could be rebuilt to work with an older glibc as the API is stable. The ABI is not which is why the application would need to be rebuilt.glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer&#x2F;older versions as needed. Maintaining a stable ABI mostly helps proprietary software where the source is not available for recompilation. Naturally the gnu guys building glibc don’t care about that use case much.I guess you didn’t mention glibc in your comment but I already typed this out

charcircuit: No other operating system works like this. Supporting older versions of an OS or runtime with a compiler toolchain a standard expectation of developers.

thescriptkiddie: what about mac os?

Jblx2: If you game&#x2F;app runs on Wine, doesn't that reduce the pressure to develop a Linux port?

BadBadJellyBean: Possibly but does it realistically matter? I don't care why my games run on linux I just care that they do. I encountered a few cases where the native version was inferior to the wine version (Cronos is one example). With wine improving there is very little downside to just using it.

fluffybucktsnek: Even if all games were FOSS, without - at least - a stable API, most games will remain a hassle to run. DOOM doesn't deal as much with this due to the high amount of volunteers, but relying on community support for all games is just outsourcing labor to some unlucky fellows. At best, it's yet another pain for Linux users. At worse, it's the death of unpopular games. Either case, a hurdle for Linux adoption.

nurettin: I met someone who bit shifts for life, uses opengl shaders for compute, but has no sql experience and is afraid of opening a tcp socket.

anthk: Trivial under plan9&#x2F;9front. Under Win32&#x2F;POSIX, run way.On bit shifts, pick any Forth programmer and shaders will be almost like a toy for them. They are used to implement double numbers (and maybe floats) themselves by hand by just reusing the only integer numbers they have and writting custom commands to output these pairs of integer as double numbers. They can probably implement multithreading processing by hand in Forth and also know the IEEE standards for floats better than C programmers over 20 years.

orbital-decay: I am gaming on Linux, playing both modern and old games. Most games are going to stay closed source in the foreseeable future, that's just a fact of life and gamedev incentives and specifics.

novos: I wouldn't put it past Microsoft to suddenly add "features" that break said support.

ptx: Is the difference between the NT-style and POSIX-style semaphores essentially just that NT (and now this new API in Linux) supports setting a max value? Why don't POSIX semaphores support this?

trentnelson: WaitForMultipleObjects is fascinating behind the scenes. A single thread can wait on up to 64 independent events, which is done by plumbing the KTHREAD data structure with literally 64 slots for dispatcher header stuff, plus all the supporting Ke&#x2F;dispatcher logic in the kernel.There’s never been a POSIX equivalent to this. It requires sophisticated kernel support and the exact same parity can’t be achieved in user space alone.

selectively: Yuck.

kelnos: Why?

kelnos: Not sure what you mean. The number of Mac games isn't relevant to a subthread about a project to increase performance when Windows games on Mac.

anthk: Anything Direct Draw related will be mapped into OpenGL under Unix giving you decent speeds. On Windows it will be a crawling slideshow because from Windows 8 and up it will use a really dog slow software mode with no acceleration at all, worse than plain VESA. Yes, you can reuse WineD3D DLL's on Windows and run these game in a fast way, but not by default, it's a Win32 port of some Wine libraries.

mschuster91: > This might sound like a small quality-of-life improvement, but it's a massive piece of engineering work. The WoW64 mode now handles OpenGL memory mappings, SCSI pass-through, and even 16-bit application support. Yes, 16-bit! If you've got ancient Windows software from the '90s that you need to run for whatever reason, Wine 11 has you covered.Does that also apply to macOS? Even on Intel machines, Apple dropped 32-bit support many many years ago and IIRC it took ugly workarounds that weren't ever part of upstream WINE but of Crossover.