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.
hxorr 1 minutes ago [-]
ReactOS also deserves an honorary mention. A lot of knowledge from that project feeds into Wine.
hu3 36 minutes ago [-]
> 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 FPS
Amazing. 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.
bmenrigh 24 minutes ago [-]
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+ntsync 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 support code compiled for Windows that expects to be talking to an NT kernel.)
iknowstuff 22 minutes ago [-]
* when not using esync nor fsync
adelmotsjr 43 minutes ago [-]
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.
dgunay 5 minutes ago [-]
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.
eurg 37 minutes ago [-]
All good. I tell people how to add another mailbox to their Outlook, "click here, now there". Not glorious. Necessary anyways.
brailsafe 38 minutes ago [-]
Start working through the layers! It's incredibly rewarding to go from just typical day job stuff to understanding bits and pieces of esoteric low level implementation. One level at a time, it's not that bad, although it is hard and takes effort. I know next to nothing either, but having felt the same way a few years ago, these kind of posts now at least excite me instead of just intimidate.
zerr 11 minutes ago [-]
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 8 minutes ago [-]
They don't. The "simplicity" of using a "high-level" framework for someone who bit-shifts for a living is almost comical.
phist_mcgee 1 minutes ago [-]
Sure mate. And the guy who can do binary sums in his head would think of assembly as mere childsplay.
Jog on.
chistev 3 minutes ago [-]
Really?
DeathArrow 21 minutes ago [-]
>People are dealing with such low level things, while i'm outta here building simple CRUDs.
CRUDs do pay the bills.
huflungdung 21 minutes ago [-]
[dead]
watashiato 32 minutes ago [-]
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 24 minutes ago [-]
>These extreme gains are the result of benching against vanilla without fsync, which is what anyone gaming on linux uses
Not for anyone using a kernel without these patches. Which would be most people.
foresto 13 minutes ago [-]
Most people? What mainstream Linux distros ship without fsync or esync support?
akdev1l 7 minutes ago [-]
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.
ticulatedspline 44 minutes ago [-]
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.
krastanov 41 minutes ago [-]
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 39 minutes ago [-]
I wouldn't be surprised if Wine eventually becomes more stable than Windows.
carlos_rpn 23 minutes ago [-]
It feels like it won't be long before Microsoft starts helping with that (by making Windows less stable, not improving Wine).
keyringlight 4 minutes ago [-]
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.
porphyra 15 minutes ago [-]
Wine actually does run some ancient Windows games better than Windows 11 itself.
duskwuff 7 minutes ago [-]
It certainly runs 16-bit Windows games better than Windows 11, which can't run them at all. Not that there are a ton of those, but it's still pretty neat that they work.
akdev1l 17 minutes ago [-]
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/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
_flux 32 minutes ago [-]
What I'd like to see would be some useful extra APIs in Wine, that would allow it to perform even better in some situations, and that such APIs would be then embraced by the game developers.
Finally some embrace, extend, and extinguish love right back at Microsoft!
zerocrates 21 minutes ago [-]
Building against the Steam runtime containers seems like the other route, which also gets you more stability.
tombert 39 minutes ago [-]
I actually think it'll be the opposite. Even for games that have native ports I pretty much always run the Windows version with Proton, since that just tends to be more stable. People develop against the Windows API because it's familiar and somewhat unchanging, and that's fine since Proton does such a good job running it.
jfaulken 42 minutes ago [-]
This is the very definition of "a good problem to have."
orbital-decay 30 minutes ago [-]
Unlikely. Games need a stable ABI and Win32 is the only stable ABI on Linux.
akdev1l 14 minutes ago [-]
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
Jblx2 31 minutes ago [-]
If you game/app runs on Wine, doesn't that reduce the pressure to develop a Linux port?
ticulatedspline 19 minutes ago [-]
short term yeah, probably hurts native ports since "why bother". Long term though if the market share for Linux is particularly high I could see more native development.
Either way my comment is intended as more humorous than truly insightful or prophetic.
cadamsdotcom 16 minutes ago [-]
Gotta get there somehow.
Normal_gaussian 39 minutes ago [-]
A solution to itself
2OEH8eoCRo0 16 minutes ago [-]
It's interesting when old Windows games run better in Wine than in actual Windows 10/11.
inetknght 14 minutes ago [-]
It's even more interesting when the latest Windows games run better in Wine than in actual Windows 10/11.
DeathArrow 20 minutes ago [-]
Quiet the other way around. Wine being good will reduce incentives for game studio to produce native Linux ports.
p_ing 42 minutes ago [-]
OS/2 part deux
LetsGetTechnicl 11 minutes ago [-]
This is such an amazing accomplishment! Absolutely wild to see Linux basically re-implement Windows and doing it better, while MS is dead set on making everything about their software worse.
dinkblam 54 minutes ago [-]
it seems if you want the same on macOS, this is the place to contribute:
That's interesting. I thought the point was that it needed to be in-kernel for performance reasons; if it works in userspace why did linux not do that?
brightball 36 minutes ago [-]
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.
Night_Thastus 25 minutes ago [-]
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......
k33n 8 minutes ago [-]
What's wrong with the Nvidia drivers for Linux?
kapija 1 hours ago [-]
awesome, finally wine is getting proper ntsync support... and i reckon wow64 will let me run so many old games...
SeriousM 16 minutes ago [-]
Does it finally support visual studio?
DeathArrow 22 minutes ago [-]
While I am not a big gamer anymore, I am curious whether this new Wine release make it possible to run Windows software such as Photoshop or Visual Studio on Linux with decent speed and decent resource usage.
freediddy 37 minutes ago [-]
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.
bmenrigh 21 minutes ago [-]
No, the gains here aren't very dramatic when compared properly (against fsync), and have nothing to do with AI help. The gains come down to Linux kernel support for certain synchronization primitives like the Mutex on Windows, such that there is a more direct mapping of what a Windows binary expects to what the Linux kernel provides. See https://docs.kernel.org/userspace-api/ntsync.html for the kernel support that makes this possible.
Rendered at 20:05:58 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
> 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 FPS
Amazing. 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.
That said, Wine+ntsync 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 support code compiled for Windows that expects to be talking to an NT kernel.)
Jog on.
CRUDs do pay the bills.
Not for anyone using a kernel without these patches. Which would be most people.
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.
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.
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/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
Finally some embrace, extend, and extinguish love right back at Microsoft!
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
Either way my comment is intended as more humorous than truly insightful or prophetic.
https://github.com/Alien4042x/Wine-NTsync-Userspace-macOS-ba...
Now if we can just get some decent Nvidia drivers......