[HN Gopher] Wine 11 rewrites how Linux runs Windows games at ker...
___________________________________________________________________
Wine 11 rewrites how Linux runs Windows games at kernel with
massive speed gains
Author : felineflock
Score : 514 points
Date : 2026-03-24 18:34 UTC (4 hours ago)
(HTM) web link (www.xda-developers.com)
(TXT) w3m dump (www.xda-developers.com)
| kapija wrote:
| awesome, finally wine is getting proper ntsync support... and i
| reckon wow64 will let me run so many old games...
| dinkblam wrote:
| it seems if you want the same on macOS, this is the place to
| contribute:
|
| https://github.com/Alien4042x/Wine-NTsync-Userspace-macOS-ba...
| yjftsjthsd-h wrote:
| 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?
| kelnos wrote:
| Ideally it _does_ need to be in-kernel for performance
| reasons. But that 's not possible on macOS, so it's better to
| have it in userspace than not at all.
| hungryhobbit wrote:
| 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).
| kelnos wrote:
| 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.
| ticulatedspline wrote:
| 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.
| jfaulken wrote:
| This is the very definition of "a good problem to have."
| p_ing wrote:
| OS/2 part deux
| ssl-3 wrote:
| Sorta, kinda, but not really.
|
| OS/2 may have been a better Windows than Windows during the
| Warp days 30-ish years ago. It was also a very competent
| operating system in its own right.
|
| We all know the story:
|
| It never had a broad base of native applications. It could
| have happened, but it did not happen. Like, back then when
| Usenet was the primary way of conducting written online
| discourse, the best newsreader I had on OS/2 was a Windows
| program; the ones that ran natively on OS/2 weren't even
| _close_.
|
| And OS/2 never had support from a popular company. There were
| times at OS/2's peak (such as it was) when it was essentially
| impossible to buy a new computer with OS/2 pre-installed and
| working correctly _even from IBM_.
|
| Linux, though? Over those same 30-ish years, a huge amount of
| native applications have been written. Tons of day-to-day
| stuff can be done very well in Linux without even a hint of
| Wine and that's been reality for quite a long time now.
|
| The missing piece, if there is one, is gaming. It'd be great
| to have more native games and fewer abstraction layers. But
| systems like Valve's popular Steam Deck and upcoming Steam
| Machine are positive aspects that OS/2 never had an
| equivalent to. And since Steam is very nearly ubiquitous,
| companies that sell computer game software _do_ pay attention
| to what Valve is doing in this space.
|
| (And frankly, when a game runs great in some
| Steam/Wine/Proton/Vulkan shapeshifting slime mold abstraction
| stack, I really do not care that it isn't running natively. I
| push the button and receive candy.)
| krastanov wrote:
| 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 wrote:
| I wouldn't be surprised if Wine eventually becomes more
| stable than Windows.
| carlos_rpn wrote:
| It feels like it won't be long before Microsoft starts
| helping with that (by making Windows less stable, not
| improving Wine).
| keyringlight wrote:
| 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.
| mschuster91 wrote:
| > What I wonder about is if MS wants to keep people on
| windows, what methods they can use to do that
|
| Microsoft doesn't give a fuck about private customers any
| more. They don't have money.
|
| What has money though is enterprise/government sales, and
| MS got these customers tightly locked in. Compliance
| audits and tooling for insurances or legal stuff (SOX,
| GDPR, ...) are _built_ against a full Microsoft stack of
| MS Server, Active Directory, Azure, Teams, Office 365 and
| Windows desktops.
|
| You might be able to get away with replacing AD and GPO
| with Samba servers but even that is already a pain when
| the auditors come knocking. Everything else? There is
| _no_ single FOSS based "standard offering" (i.e. a
| combination of everything needed to run an on-prem
| enterprise site, Office replacement, remote collaboration
| tooling), so every audit for such setups must be custom
| made and involves a lot of extra work.
|
| A second leg is industrial control machines, medical
| devices and the likes. That's all stuff built by third
| party vendors and integrators. They need to continue on
| Windows because switching to an alternative OS would
| require redoing _everything_ from scratch on the software
| and certification side. These customers buy the LTSC IoT
| stuff.
|
| And that is why you see Microsoft pushing
| enshittification so hard on private customers... extract
| the last few cents you can from them. But the real money
| comes from the large customers.
| porphyra wrote:
| Wine actually does run some ancient Windows games better
| than Windows 11 itself.
| duskwuff wrote:
| 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.
| anthk wrote:
| 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.
| Aerroon wrote:
| Windows 14 will just be a linux distro with wine acting as
| backwards compatibility.
| voodooEntity wrote:
| Inb4 Windows 40k and to run the "kernel" you need to
| sacrifice 1000 a day
| alexrp wrote:
| I've experienced multiple instances where (so I heard; I
| don't use Windows) a Windows Update completely broke a game
| on Windows for everyone, but Wine/Proton kept running it
| just fine. So we're already there in some sense.
| _flux wrote:
| 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 wrote:
| Building against the Steam runtime containers seems like the
| other route, which also gets you more stability.
| akdev1l wrote:
| 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
| charcircuit wrote:
| No other operating system works like this. Supporting older
| versions of an OS or runtime with a compiler toolchain a
| standard expectation of developers.
| akdev1l wrote:
| Plenty of operating systems work like this. Just not
| highly commercial ones because proprietary software is
| the norm on those.
|
| From a bit of research it looks like FreeBSD for example
| only provides a stable ABI within minor versions and I
| imagine if you build something for FreeBSD 14 it won't
| work on 13.
|
| Stable ABI literally only benefits software where the
| user doesn't have the source. Any operating system which
| assumes you have the source will not prioritize it.
|
| (Edit: actually thinking harder MacOS/iOS is actually
| much worse on binary compatibility, as for example Intel
| binaries will stop working entirely due to M-cpu
| transition - Apple just hits developers with a stick to
| rebuild their apps)
| kelnos wrote:
| Yes, and this is a great reason why FreeBSD isn't a
| popular gaming platform, or for proprietary software in
| general. I'm not saying this is a bad thing, but...
| that's why.
|
| > _Stable ABI literally only benefits software where the
| user doesn't have the source._
|
| It also benefits people who don't want to have to do
| busywork every time the OS updates.
| toast0 wrote:
| FreeBSD isn't _too_ bad, you can build /install compat
| packages back to FreeBSD 4.x, and I'd expect things to
| largely work. At previous jobs we would mostly build our
| software for the oldest FreeBSD version we ran and
| distribute it to hosts running newer FreeBSD releases and
| outside some exceptional cases, it would work. But you'd
| have to either only use base libraries, or be careful
| about distribution of the libraries you depend on. You
| can't really use anything from ports, unless you do the
| same build on oldest and distribute plan.
|
| At Yahoo, we'd build on 4.3-4.8, and run on 4.x - 8.x. At
| WhatsApp, I think I remember mostly building on 8.x and
| 9.x, for 8.x - 11.x. The only thing that I remember
| causing major problems was extending the bitmask for CPU
| pinning; there were a couple updates where old software +
| old kernel CPU pinning would work, and old software + new
| kernel CPU pinning failed; eventually upstream made that
| better as long as you don't run old software on a system
| with more cores than fit in the bitmask. I'm sure there
| were a few other issues, but I don't remember them ...
| charcircuit wrote:
| You can still run x86 binaries on new macbooks. They
| don't stop working entirely. Using wine I can even run
| x86 windows binaries.
| akdev1l wrote:
| They announced Rosetta 2 will be deprecated and
| eventually removed (MacOS 28?)
|
| By that point they already hit the developers enough to
| get them to port to aarch64
|
| (arguably though this could be a special case because it
| is due to architectural transition)
| thescriptkiddie wrote:
| what about mac os?
| kelnos wrote:
| macOS doesn't require developers to rebuild apps with
| each major OS release, as long as they link with system
| libraries and don't try to (for example) directly make
| syscalls.
|
| _Apple_ may require rebuilds at some point for their Mac
| Store (or whatever they call it), but it 's not required
| from a technical perspective.
|
| The one exception here is CPU architecture changes, and
| even then, Apple has provided seamless
| emulation/translation layers that they keep around for
| quite a few years before dropping support.
| charcircuit wrote:
| The latest Xcode supports targeting back to macOS 11.
| This covers >99% of macs which is acceptable for most
| developers.
|
| https://developer.apple.com/support/xcode/
| kelnos wrote:
| > _What glibc does not provide is forward compatibility. An
| application built with glibc 2.12 will not necessarily work
| with any older version._
|
| Is this correct? I think you perhaps have it backward? If I
| compile something against the glibc on my system (Debian
| testing), it may fail to run on older Debian releases that
| have older glibc versions. But I don't see why an app built
| against glibc 2.12 wouldn't run on Debian testing. glibc
| actually does a good job of using symbol versioning, and
| IIRC they haven't _removed_ any public functions, so I don
| 't see why this wouldn't work.
|
| More at issue would be the availability of other
| dependencies. If that old binary compiled against glibc
| 2.12 was also linked with, say, OpenSSL 0.9.7, I'd have to
| go out and build a copy of that myself, as Debian no longer
| provides it, and OpenSSL 3.x is not ABI-compatible.
|
| > _glibc does not provide ABI compatibility because from
| their perspective the software should be rebuilt for newer
| /older versions as needed._
|
| If true (I don't think it is), that is a hard showstopper
| for most companies that want to develop for Linux. And I
| wouldn't blame them.
| akdev1l wrote:
| Sorry I am not sure if 2.12 is a a recent release or
| older, I made up this number up
|
| If the application is built against 2.12 it may link
| against symbols which are versioned 2.12 and may not work
| against 2.11 - the opposite (building against 2.11 and
| running on 2.12) will work
|
| >If true (I don't think it is), that is a hard
| showstopper for most companies that want to develop for
| Linux.
|
| Not really a show stopper, vendors just do what vendors
| do and bundle all their dependencies in. Similar to
| windows when you use anything outside of the win32 API.
|
| The only problem with this approach is that glibc cannot
| have multiple versions running at once. We have "fixed"
| this with process namespaces and hence containers/flatpak
| where you can bundle everything including your own glibc.
|
| Naturally the downside is that each app bundles their own
| libraries.
| em-bee wrote:
| _The only problem with this approach is that glibc cannot
| have multiple versions running at once_
|
| that's not correct. libraries have versions for a reason.
| the only thing preventing the installation of multiple
| glibc versions is the package manager or the package
| versioning.
|
| this makes building against an older version of glibc
| non-trivial, because there isn't a ready made package
| that you can just install. the workarounds take effort:
|
| https://stackoverflow.com/questions/2856438/how-can-i-
| link-t...
|
| the problem for companies developing on linux is that it
| is not trivial
| krastanov wrote:
| I am sorry, I did not mean to imply anyone else is doing
| something poorly. I believe glibc's (and the rest of the
| ecosystem of libraries that are probably more limiting)
| policies and principled stance are quite correct and
| overall "good for humanity". But as you mentioned, they are
| inconvenient for a gamer that just wants to run an
| executable from 10 years ago (for which the source was lost
| when the game studio was bought).
| HerbManic wrote:
| Ever since Proton came along, it has been a quiet agreement
| that Win32 APIs are the best target for Linux support.
| Normal_gaussian wrote:
| A solution to itself
| tombert wrote:
| 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.
| Jblx2 wrote:
| If you game/app runs on Wine, doesn't that reduce the pressure
| to develop a Linux port?
| ticulatedspline wrote:
| 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.
| BadBadJellyBean wrote:
| 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.
| orbital-decay wrote:
| Unlikely. Games need a stable ABI and Win32 is the only stable
| ABI on Linux.
| akdev1l wrote:
| 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
| fluffybucktsnek wrote:
| 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.
| LtWorf wrote:
| People who keep parroting this clearly have no experience of
| gaming on linux.
| fluffybucktsnek wrote:
| Please elaborate.
| LtWorf wrote:
| Wine has constant regressions. What works fine today will
| completely fail next year. Which is why steam lets you
| pick which proton version you want to use.
|
| Which means that a .exe without the exact version of wine
| won't run.
|
| Plus of course there's the whole vulkan stuff. Older
| cards aren't well supported but it will rather crash than
| just run openGL normally where it would work fine.
| orbital-decay wrote:
| In practice, Wine is constantly improving. It's in active
| development and not that stable, but regressions are
| mostly local. Treat its releases like bleeding edge.
|
| _> What works fine today will completely fail next
| year._
|
| Usually not on the timescale of a year. I have many new
| games that worked a year ago and none of these stopped
| working now. The worst breakage I had recently was some
| physics glitches in an old RPG (released in 2001) on Wine
| 11.0, and it was fixed in the next release.
| fluffybucktsnek wrote:
| Those issues seem othorgonal to stable ABI issue from OP,
| specially the OpenGL one (that is more like a hardware
| incompatibility issue). When apps fail to run due to Wine
| updates, they are considered bugs to be fixed. On the
| native side, apps may break becuase: 1) required library
| is unavailable, normally because it is too old and
| unsupported; 2) required library's path is different in
| distro A from B. None of these are considered bugs and,
| as such, are rarely addressed. I believe Steam Linux
| Runtime is an attempt at fixing this,but I'm not sure
| about its effectiveness. Also, you are exaggerating on
| the "exact Wine version". It helps to know which versions
| don't have a regression by knowing which specific version
| an app used to run on.
| orbital-decay wrote:
| I am playing both modern and old games on Linux. Games
| outside a super narrow enthusiast realm are always closed-
| source (even indie ones) and it's going to stay like that
| in the foreseeable future, that's just a fact of life and
| gamedev incentives and specifics.
| TheCycoONE wrote:
| Are you able to run any of the old Loki games on Linux
| these days?
| anthk wrote:
| With compat libraries and OSSPD it will run even under
| Pulseaudio.
| DeathArrow wrote:
| Quiet the other way around. Wine being good will reduce
| incentives for game studio to produce native Linux ports.
| cadamsdotcom wrote:
| Gotta get there somehow.
| 2OEH8eoCRo0 wrote:
| It's interesting when old Windows games run better in Wine than
| in actual Windows 10/11.
| inetknght wrote:
| It's even more interesting when the latest Windows games run
| better in Wine than in actual Windows 10/11.
| marssaxman wrote:
| It seems more likely to me that the Windows API will become the
| de-facto Linux gaming SDK, and the idea of porting a game to
| Linux will become meaningless.
| FpUser wrote:
| If I had a guarantee that every windows application that is
| important to me runs on Wine I would switch next day. Now I use
| Windows to develop both - Windows and Linux applications even
| when primary running mode for application is business backend
| on Linux
| kelnos wrote:
| I don't think this is a big concern. There will still be plenty
| of demand for Wine even with a decent catalog of Linux-native
| games. People use Wine for things other than games, and even if
| tomorrow every single new game had a native Linux port, people
| would still be playing older Windows-only games for at least
| another 20 years, probably more.
|
| Also the Windows ABI is still more stable than the Linux ABI.
| Even if Linux (non-SteamDeck) gaming share went up to like 50%
| or more, it still would probably be less of a hassle to build
| for Windows only, the performance difference on Linux+Wine
| isn't enough to matter.
| nialv7 wrote:
| There always will be old games that will never be ported to
| Linux.
| adelmotsjr wrote:
| 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.
| brailsafe wrote:
| 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.
| eurg wrote:
| All good. I tell people how to add another mailbox to their
| Outlook, "click here, now there". Not glorious. Necessary
| anyways.
| DeathArrow wrote:
| >People are dealing with such low level things, while i'm outta
| here building simple CRUDs.
|
| CRUDs do pay the bills.
| zerr wrote:
| 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 wrote:
| They don't. The "simplicity" of using a "high-level"
| framework for someone who bit-shifts for a living is almost
| comical.
| chistev wrote:
| Really?
| bombcar wrote:
| 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.
| anthk wrote:
| Myself. Forth it's easy, 9front C it's manageable but
| POSIX it's hell and managing both Unix descendants are a
| piece of cake.
|
| GUI interfaces for the enterprise came from Dante's hell
| themselves. I hate them, they are like the Madhouse from
| that Asterix movie making satire of the European
| bureucracy of the day. The often are oddly designed and
| they are not documented at all, you must guess the
| meaning by chance of with a senior tutoring you.
|
| The same with anything corporate from Microsoft with AD
| roles/group policies and the like. Or anything coming
| from IBM.
| phist_mcgee wrote:
| Sure mate. And the guy who can do binary sums in his head
| would think of assembly as mere childsplay.
|
| Jog on.
| nurettin wrote:
| 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 wrote:
| Trivial under plan9/9front. Under Win32/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.
| -drews wrote:
| I felt this way moving from embedded into backend for the
| first time and having no idea where to start. Was incredibly
| daunting, but both domains become trivial over time.
| Rick76 wrote:
| Can confirm, my buddy who is someone I respect immensely, is
| an embedded programmer.
|
| He will talk about OS events, or any low level concept and it
| makes me feel like I don't know anything, but he acts like
| I'm a genius if I talk about JavaScript Runtimes, browser
| engines, anything frontend.
|
| It's cool he teaches me new things, I teach him some
| __natty__ wrote:
| Some people are exceptional at solving difficult but hard
| to explain problems while other are great solving direct
| business problems. No need to feel ashamed for both it's
| just different work
| dgunay wrote:
| 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.
| dmitrygr wrote:
| Play with low level things. It'll help you in your daily job in
| ways you do not yet imagine. Start here: nandgame.com
| Teknoman117 wrote:
| 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.
| zem wrote:
| 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.
| johnnyanmac wrote:
| Meanwhile, I can't really do either because the job market
| sucks and I don't have time to contribute the way I want to to
| project like this.
| pier25 wrote:
| Same. I feel like a plumber compared to real engineers.
| dole wrote:
| You're still an engineer. Knowing the right places to click
| in an esoteric app is like knowing where to hit the boiler
| with a hammer to get it working again.
| kalinkochnev wrote:
| Engineers feel like plumbers compared to the plumbers
| wishfish wrote:
| Not only do the CRUDs have value but they're good for your
| sanity. I knew a guy back in the dot-com era. Very skilled
| coder. Backbone of the company. He pulled off miracles.
| Fulfilled impossible deadlines. Then one day, out of the blue,
| he quit. Took a job at a non-technical corp. They put him in a
| cubicle where he wrote Visual Basic CRUDs on an 8-5 schedule.
| No weird deadlines, no sleeping under the desk. He called it
| his paid vacation.
| crtified wrote:
| Don't feel too bad - I had to Google what CRUD means. :D
| freediddy wrote:
| 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 wrote:
| 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.
| hu3 wrote:
| > 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 wrote:
| 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.)
| creesch wrote:
| > There has been a somewhat fast "fsync" library built around
| Linux's futex
|
| The article actually goes into that in quite a bit of detail
| about that.
| bmenrigh wrote:
| 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.
| iknowstuff wrote:
| * when not using esync nor fsync
| ToucanLoucan wrote:
| So, what's the relationship between Wine and Proton? Is Proton
| just the SteamOS/Valve name for it, or is it actually it's own
| project?
| jeppester wrote:
| It's a distribution of Wine with some extra stuff added,
| importantly DXVK (directx => vulkan layer) and a lot of game
| specific workarounds.
| gpderetta wrote:
| More or less Wine + some experimental patches not yet I
| twgrated in mainstream wine + a buch of DirectX translation
| libraries + close steam integration.
| ToucanLoucan wrote:
| That makes sense. I thought they were entirely separate tbh
| but it makes sense that they'd share a lot of DNA.
|
| I absolutely love my Ally running SteamOS. Incredible work
| by... everyone involved, really.
| rounce wrote:
| Though currently Proton has not yet shipped a release which
| uses Wine 11.
| tombert wrote:
| 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 wrote:
| ReactOS also deserves an honorary mention. A lot of knowledge
| from that project feeds into Wine.
| pdpi wrote:
| And vice-versa. It's pretty interesting that the two projects
| haven't kind of merged despite all the collaboration.
| MisterTea wrote:
| Very different projects so I would not encourage a merge
| but sharing a code base? I can totally see that being a
| boon for both and other Windows emulation projects.
| Induane wrote:
| ReactOS periodically rebases some of it's libraries from
| Wine.
| rhdunn wrote:
| Wine has a lot of tests that are run across platforms to check
| conformance -- https://test.winehq.org/data/. These are a large
| part of why it has good compatibility.
| refulgentis wrote:
| I simply wouldn't have the patience to do what Elizabeth did,
| for a month, much less years. Really really impressive
| anal_reactor wrote:
| Yes, Wine is truly a miracle. Once full support for Office is
| achieved, we should expect huge uptick in Linux adoption.
| jhoechtl wrote:
| Ny that time office will be cloud only.
| m463 wrote:
| > full support for office
|
| does microsoft still sell office?
| ThrowawayB7 wrote:
| Yes, Microsoft does still sell MS Office 2024 as a one time
| purchase:
|
| - https://www.microsoft.com/en-us/microsoft-365/p/office-
| home-...
|
| - https://www.microsoft.com/en-us/microsoft-365/p/office-
| home-...
| tom_alexander wrote:
| Outlook is a business exclusive these days?! Outlook used
| to be included in the most basic version of office back
| when I still used microsoft office.
| dhosek wrote:
| I've only ever used Outlook when forced to by an employer
| and I find it a dreadful application to use. I would
| guess that most people prefer something else. I would
| imagine that most people tend to stick with the default
| email app on their computer (no idea what that is on
| Windows as I've managed to avoid having to use Windows
| for 7 years now).
| Asmod4n wrote:
| Will be removed from the next release. Then you can't
| connect to your own exchange server anymore and are
| forced into 365 when you want a desktop app.
| pkaye wrote:
| Yes the do have an one time purchase option. You get 5
| years of updates but no new features. I have it on my home
| computers. But new features are not a big deal since the
| differences are not big anymore (just like mobile phones.)
| novos wrote:
| I wouldn't put it past Microsoft to suddenly add "features"
| that break said support.
| mrec wrote:
| "Office ain't done 'til Wine won't run"?
| RachelF wrote:
| It is a superb project, and a hard thing to do.
|
| It is a pity that the apps most business people use everyday,
| like Word and Excel and Outlook don't work in it (Excel 2010 is
| the last version that has Platinum status). It is interesting
| that these are harder to get working than games.
| coldpie wrote:
| > It is interesting that these are harder to get working than
| games.
|
| Games are mostly just doing their own thing, only interacting
| with the system for input & output. MS Office is using every
| single corner of Windows: every feature in the XML libraries,
| tons of .NET type stuff, all the OLE and COM and typelib and
| compound storage features, tons of Explorer integrations,
| auto-updating stuff via Windows patching mechanisms...
| there's almost no corner of the Windows OS that MS Office
| _doesn 't_ use.
| joe_mamba wrote:
| You're onto something but that's not entirely true for all
| games. There's plenty of vintage games, made before DirectX
| standardized everything into the late 90s, that don't work
| well under wine because back in their day, they would try
| to bypass windows by "hacking" their way to the hardware
| via unsupported APIs and hooks, to squeeze every bit of
| performance from the hardware, and also because every
| hardware vendor back then from graphics to sound shipped
| their own APIs.
| Asmod4n wrote:
| You mean dos games, just run them under a dos emulator
| then.
| joe_mamba wrote:
| NO, I meant Windows games.
| vbezhenar wrote:
| > Games are mostly just doing their own thing, only
| interacting with the system for input & output.
|
| They should be trivial to port then, no?
| Rohansi wrote:
| Yes, they are easy to port a lot of the time. Especially
| now because you can use DXVK to translate DirectX calls
| into Vulkan, so you don't need to write a Vulkan
| renderer. Input is sometimes a trickier one to deal with
| but a lot of the time games are using cross-platform
| libraries for that already!
|
| Despite all this the Unity engine has spotty Linux
| support. Some games run better under Wine vs. Unity's
| native Linux builds. It's Vulkan renderer has had a
| memory leak for a while now. Input has randomly decided
| to double keypresses on some distros.
| p1necone wrote:
| Yeah but Windows is a more stable api to develop against
| than Linux (at least when it comes to stuff that games
| need to do) - it doesn't feel "pure", but pragmatically
| it's much better as a game developer to just make sure
| the Windows version works with proton than it is to
| develop a native linux version that's liable to break the
| second you stop maintaining it.
| RajT88 wrote:
| Parts of the OS were designed for Office. (Windows
| installer service, for example)
| philipwhiuk wrote:
| I don't know that they are. It's just there's more incentive
| to port stuff that has no direct alternative.
| computomatic wrote:
| I avoided using Wine (and Linux for gaming generally) for years
| on the sole basis that I assumed what they were trying to do
| was impossible to do well. Occasionally I'd try wine for some
| simple game and be impressed it worked at all, but refused to
| admit to myself that it was something I could rely on. (This
| was many years ago and I freely admit today that I was wrong.)
| ACS_Solver wrote:
| Valve's Proton (so Wine + DXVK + some other additions)
| revolutionized gaming on Linux. I play games both for fun and
| work, and for a solid 3+ years now, gaming on Linux has been
| an "it just works" experience for me, and should be for most
| games that don't use kernel-level anticheat.
| owaislone wrote:
| I really is impressive. I wish publishers like EA and anti-
| cheat developers weren't so reluctant to support it. I hope
| Steam devices and SteamOS gain enough traction to force
| their hands.
| amatecha wrote:
| https://www.gamingonlinux.com/2026/03/ea-javelin-
| anticheat-j...
| vbezhenar wrote:
| Same here. Never used it and don't plan to use it. Would
| rather keep Windows installation for games. I think this
| whole thing is a bunch of hacks.
| kyorochan wrote:
| You're saying the opposite of what the person you think
| you're agreeing with is.
| exe34 wrote:
| I look forward to your conversion 20 years from now.
| aranelsurion wrote:
| I remember managing to play Crysis under Linux with Wine and
| I was SO impressed. Never would've imagined one day almost
| every game would be playable.
| Perepiska wrote:
| I've tried to use Wine in order to play Steam Windows games on
| Mac. Wine silently exposes all my macos drives as D:/F:/etc
| that was open to any game I started. Immediately removed Wine.
| Awful experience.
| dhosek wrote:
| Way back in the 90s when I used OS/2 and running Windows
| applications required running a fully copy of Windows inside
| OS/2,1 I had dreamed of writing something akin to Wine for
| OS/2, but I lacked the knowledge to do it back then (and still
| do). I've never used it since I never use Linux in a context
| that it would make sense (for me, as is the case for most Linux
| users I suspect, Linux is strictly a headless server OS).
| Apparently Wine is also available for the Mac, but these days I
| don't know of a single Windows app2 that I would want to run.
|
| [?]
|
| 1. A frequent debate about the time was whether this was a wise
| thing to do as it reduced the motivation for developers to
| create OS/2-native versions of applications. The slow death of
| OS/2 can be interpreted as both support for those who felt that
| Windows-under-OS/2 was a bad idea and those who felt that OS/2
| was doomed from the start in the face of the Windows monopoly.
|
| 2. Largely because I'm not a gamer--when I've looked at what it
| takes, both in terms of hardware and in learning how to do
| stuff in games, I've decided that I'm happy staying that way.
| alilikestech wrote:
| With AI, you can automate all the grunt work.
| Kuraj wrote:
| I guess the silver lining is that the Windows ABI is extremely
| stable
| brightball wrote:
| 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.
| watashiato wrote:
| 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 wrote:
| >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 wrote:
| Most people? What mainstream Linux distros ship without fsync
| or esync support?
| akdev1l wrote:
| 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.
| foresto wrote:
| The common gaming-focused Wine/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 wrote:
| 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 wrote:
| > if Valve didn't enable that on their build then I don't
| have it.
|
| The Proton build _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://github.com/ValveSoftware/Proton/?tab=readme-ov-
| file#...
| akdev1l wrote:
| I thought you meant Proton-GE or such other patched
| builds of proton.
| kelnos wrote:
| I would assume most of them? I'd be surprised if distros
| like Debian, Ubuntu, Fedora, etc. would ship non-mainline
| kernel features like that.
|
| Sure, gaming-focused distros, or distros like Arch or
| Gentoo might (optionally or otherwise), but _mainstream_?
| Probably not.
|
| Of course, esync doesn't require kernel patches, so I
| imagine that was more broadly out there. But it sounds like
| fsync got you performance pretty close to what ntsync can
| do, but esync was quite a bit behind both? With vanilla
| being quite a bit behind esync?
|
| (Also, jeez, fsync, what a terrible name. fsync is a
| syscall that has to do with filesystem data. So confusing.)
| nialv7 wrote:
| esync and fsync both use mainline kernel features.
| genthree wrote:
| Last I checked, every distro of note had its own patchset
| that included stuff outside the vanilla kernel tree. Did
| that change? I admit I haven't looked at any of that
| in... oh, 15 years or so.
| foresto wrote:
| > I would assume most of them? I'd be surprised if
| distros like Debian, Ubuntu, Fedora, etc. would ship non-
| mainline kernel features like that.
|
| It's best not to assume with these things. With my stock
| Debian Stable kernel, Proton says this:
|
| fsync: up and running.
|
| And when I disable fsync, it says this:
|
| esync: up and running.
|
| > But it sounds like fsync got you performance pretty
| close to what ntsync can do, but esync was quite a bit
| behind both?
|
| No, esync and fsync trade blows in performance. Here are
| some measurements taken by Kron4ek, who maintains
| somewhat widely used Wine/Proton builds:
|
| https://web.archive.org/web/20250315200334/https://flight
| les...
|
| https://web.archive.org/web/20250315200424/https://flight
| les...
|
| https://web.archive.org/web/20250315200419/https://flight
| les...
|
| > With vanilla being quite a bit behind esync?
|
| Yes, vanilla Wine has historically fallen behind all of
| them, of course.
|
| > Also, jeez, fsync, what a terrible name. fsync is a
| syscall that has to do with filesystem data. So
| confusing.
|
| We can agree on this. :)
| IshKebab wrote:
| The article says fsync uses futexes which are a completely
| standard kernel feature.
| Night_Thastus wrote:
| 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 wrote:
| What's wrong with the Nvidia drivers for Linux?
| Duralias wrote:
| In practically every benchmark the Linux Nvidia drivers
| notably underperform compared to the windows driver.
| Night_Thastus wrote:
| They're garbage. They're bad enough that If you have an
| Nvidia GPU, it's borderline impractical to game on Linux. You
| can, but you'll be cutting framerates in half or more in many
| cases.
| DeathArrow wrote:
| 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.
| hungryhobbit wrote:
| Linux runs VS Code just fine. If you mean the larger Visual
| Studio suite ... why on earth would anyone want to run that
| garbage pile on Linux?
| dmitrygr wrote:
| At least for the last decade Visual Studio and Photoshop ran
| just fine on wine.
| SeriousM wrote:
| Does it finally support visual studio?
| LetsGetTechnicl wrote:
| 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.
| jordand wrote:
| The full 16bit support here is a big thing especially given
| 64bit Windows (now everywhere) dropped it. With old games,
| there's thousands that are 16bit, and even odd cases where the
| game is 32bit but the installer for it is 16bit.
| lifis wrote:
| 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?
| evmar wrote:
| I don't know the technical details, but the kernel docs say "It
| exists because implementation in user-space, using existing
| tools, cannot match Windows performance while offering accurate
| semantics." https://docs.kernel.org/userspace-api/ntsync.html
| topspin wrote:
| > It seems like it would be possible to implement this in
| userspace using shared memory
|
| It is not. Perhaps this should be possible, but Linux doesn't
| provide userspace facilities that would be necessary to do this
| entirely in userspace.
|
| This is not merely an API shim that allows Windows binary
| object to dynamically link and run. It's an effort to recreate
| the behavior of NT kernel synchronization and waiting
| semantics. To do this, Linux kernel synchronization primitives
| and scheduler API must be used. You can read the code[1] and
| observe that this is a compatibility adapter that relies
| heavily on Linux kernel primitives and their coordination with
| the kernel scheduler. No approach using purely user space
| synchronization primitives can do this both efficiently and
| accurately.
|
| [1]
| https://github.com/torvalds/linux/blob/master/drivers/misc/n...
| lifis wrote:
| The code doesn't really seem to use any kernel functionality
| other than spinlocks/mutexes and waiting and waking up tasks.
|
| That same code should be portable to userspace by: -
| Allocating everything into shared memory, where the shared
| memory fd replaces the ntsync device fd
|
| - Using an index into a global table of object pointers
| instead of object fds
|
| - Using futex-based mutexes instead of kernel spinlocks
|
| - Using a futex-based parking/unparking system like
| parking_lot does
|
| Obviously this breaks if the shared memory is corrupted or if
| you SIGKILL any process while it's touching it, but for Wine
| getting that seems acceptable. A kernel driver is clearly
| better though for this reason.
| dangoodmanUT wrote:
| I had to close 3 ads before even half my screen was the article
|
| And then it never was more than half...
| sph wrote:
| I am glad that a portion of the thousands of dollars I've given
| to Valve Corporation over the years has been gone to improve Wine
| for everybody. I wonder how many developers and contractors on
| the project are paid by Valve.
| philipwhiuk wrote:
| 2/3 of the developers on Wine work for CodeWeavers who have a
| substantial contract with Valve for Proton (a Wine fork/spin).
|
| So most of it.
| ptx wrote:
| 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 wrote:
| 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/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.
| modeless wrote:
| Yeah I was wondering if some native Linux apps might want to
| use it, since it is clearly useful and hard to emulate.
| evmar wrote:
| If you're interested in technical notes on how the WoW64 thing
| works, I dug into Wine and implemented a similar thing in my (far
| inferior) emulator and wrote about it here, including some links
| to some Wine resources:
| https://neugierig.org/software/blog/2023/08/x86-x64-aarch64....
| vintagedave wrote:
| Nice. Highly complex, I'd be interested in reading more posts
| on how your emulator works too!
|
| FYI the link to the Rosetta branch at the end 404s. Maybe
| change the point to the main repo?
| selectively wrote:
| Yuck.
| kelnos wrote:
| Why?
| mschuster91 wrote:
| > 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.
| hatmanstack wrote:
| Anybody know if NTSYNC support is why the Chrome OS team moved
| away from native Steam support?
| Blackthorn wrote:
| I've heard in the past that ntsync is a big deal for audio
| plugins via yabridge as well. Not sure how much that's going to
| reduce the existing CPU penalty there.
| oompydoompy74 wrote:
| Not that it really matters, but does this article read as LLM
| authored to anyone else?
| Twisol wrote:
| I saw signs of both human and LLM authorship, so it's probably
| at least not _slop_. It did take me out of it a bit though,
| yes.
| mft_ wrote:
| This is great.
|
| Not to sound snarky, but now please get it to run Microsoft
| Office. I'd argue that this is the last barrier to many, many
| people being able to use Linux full-time for business purposes.
___________________________________________________________________
(page generated 2026-03-24 23:00 UTC)