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.
show comments
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 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.
show comments
lifis
It seems like it would be possible to implement this in userspace using shared memory to store the data structures and using just one eventfd per thread to park/unpark (or a futex if not waiting for anything else), which should be fully correct and have similar or faster performance, at the cost of not being secure or robust against process crashes (which isn't a big problem for more Wine usage).
It seems that neither esync or fsync do this though - why?
Claude thinks that "nobody was motivated enough to write and debug the complex shared-memory waiter-list logic when simpler (if less correct) approaches worked for 95% of games, and when correctness finally mattered enough, the kernel was the more natural place to put it". Is that true?
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.
show comments
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.
show comments
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.
show comments
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.
LetsGetTechnicl
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.
show comments
dinkblam
it seems if you want the same on macOS, this is the place to contribute:
awesome, finally wine is getting proper ntsync support... and i reckon wow64 will let me run so many old games...
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......
show comments
SeriousM
Does it finally support visual studio?
DeathArrow
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.
show comments
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.
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.
> 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.
It seems like it would be possible to implement this in userspace using shared memory to store the data structures and using just one eventfd per thread to park/unpark (or a futex if not waiting for anything else), which should be fully correct and have similar or faster performance, at the cost of not being secure or robust against process crashes (which isn't a big problem for more Wine usage).
It seems that neither esync or fsync do this though - why?
Claude thinks that "nobody was motivated enough to write and debug the complex shared-memory waiter-list logic when simpler (if less correct) approaches worked for 95% of games, and when correctness finally mattered enough, the kernel was the more natural place to put it". Is that true?
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.
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.
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.
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.
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.
it seems if you want the same on macOS, this is the place to contribute:
https://github.com/Alien4042x/Wine-NTsync-Userspace-macOS-ba...
awesome, finally wine is getting proper ntsync support... and i reckon wow64 will let me run so many old games...
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......
Does it finally support visual studio?
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.
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.