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.
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.)
To be fair, early wine (when I first tried it) wasn't very usable, and for gaming specifically. So if you were an early enthusiast adopter, you might've just experienced their growing pains.
Also, I assume some Windows version jumps didn't make things easy for Wine either lol
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.
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.
You seem to have missed this part of the comment you replied to:
> This was many years ago and I freely admit today that I was wrong.
Personally I stopped using Windows for gaming because it literally doesn't work anymore. I installed Windows 11 on my gaming VM and DLSS and FSR were just completely broken, didn't work at all. Couldn't figure it out. Switched to Linux (Bazzite for now) and I have no regrets; the only games that don't work are the dangerous time-wasters (live service games with invasive anti-cheat) that I have less and less time for as I age.
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.
> 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.
So that's what's keeping Microsoft from just running WINE on an MS-flavored Linux or perhaps a clean slate kernel as their next OS. I've been wondering for a while, this is by far the best explanation.
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.
The hard part of Linux ports isn't the first 90% (Using the Linux APIs). It's the second 90%.
Platform bugs, build issues, distro differences, implicitly relying on behavior of Windows. It's not just "use Linux API", there's a lot of effort to ship properly. Lots of effort for a tiny user base. There's more users now, but proton is probably a better target than native Linux for games.
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.
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.
90s Windows ran inside of DOS, and you can run e.g. Windows 98 games (through Windows itself) in DOSBox. Look up exowin9x where they're trying to compile all of the necessary configs for one-click launchers.
Steam and CodeWeavers contribute a lot of code to the Wine project, because it underpins their business models of supporting Windows games on non-Windows platforms.
Between them they make up the vast bulk of what actually gets attention and improvement in Wine, and neither one has any interest in supporting non-game applications.
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.
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.
Way back in the 90s when I used OS/2 and running Windows applications required running a fully copy of Windows inside OS/2,¹ 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 app² 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.
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).
The default mail app on Windows is now called Outlook for Windows, no relation to the Outlook in Office (sorry, Microsoft 365 Copilot), and it's a significantly worse barely functional webview. It also replaced the entire Calendar app, which was decent.
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.)
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.
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.)
More or less Wine + some experimental patches not yet I twgrated in mainstream wine + a buch of DirectX translation libraries + close steam integration.
There's also Proton-GE [1], which is even more experimental and adds some bleeding edge fixes and features.
I've heard it's pretty good for fixing video playback/rendering (e.g. cutscene) issues if both the stable and the experimental branch of Proton can't make it work.
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.
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.
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.
> 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.
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.)
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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.
Why do people belittle CRUDs? Or even call them that? I have written quite a few applications, where there was a frotend which displayed things stored in a SQL db, with certain operations allowing you to modify said db, which I guess would fall into the CRUD variety, but the least of the complexity, and usefullness lay in that fact.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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!
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
> 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.
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.
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:
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).
No other operating system works like this. Supporting older versions of an OS or runtime with a compiler toolchain a standard expectation of developers.
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)
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.
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 ...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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
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?
> 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.
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.
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
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.
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.
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.
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.
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?
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.
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).
Hm, speculating a bit, but it feels like NTSYNC is essentially a beginning of NT Subsystem for Linux, or maybe ntoskrnl as a kernel module. Feels like the most clean and fast way to port Windows, since the rest of the interfaces are in the user space in real Windows.
Essentially should be almost without overhead: user: [gdi32.dll,user32.dll,kernel32.dll -> ntdll.dll] -> kernel: [ntoskrnl.ko]
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....
Hey thanks! I don't mean to hijack this great wine news with my own project, but since you asked, the top of the post has links to more. I will fix the link.
Support for Xbox Game Pass games (typically deployed as UWP / containerized) would be absolutely amazing and likely the final nail in the coffin for Windows for gaming for many people.
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.
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?
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.
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.
> 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.
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.
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.
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.
Also, I assume some Windows version jumps didn't make things easy for Wine either lol
> This was many years ago and I freely admit today that I was wrong.
Personally I stopped using Windows for gaming because it literally doesn't work anymore. I installed Windows 11 on my gaming VM and DLSS and FSR were just completely broken, didn't work at all. Couldn't figure it out. Switched to Linux (Bazzite for now) and I have no regrets; the only games that don't work are the dangerous time-wasters (live service games with invasive anti-cheat) that I have less and less time for as I age.
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.
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.
They should be trivial to port then, no?
I have a Windows game I can't run under CrossOver (aka Wine 11) or a VM, only because its anti-piracy layer doesn't accept those circumstances.
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.
Platform bugs, build issues, distro differences, implicitly relying on behavior of Windows. It's not just "use Linux API", there's a lot of effort to ship properly. Lots of effort for a tiny user base. There's more users now, but proton is probably a better target than native Linux for games.
There are the more obvious ones like 3DFX/Glide, but there was also stuff like the Diamond Edge 3D, which used Sega Saturn style "quads".
Between them they make up the vast bulk of what actually gets attention and improvement in Wine, and neither one has any interest in supporting non-game applications.
⸻
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.
does microsoft still sell office?
- https://www.microsoft.com/en-us/microsoft-365/p/office-home-...
- https://www.microsoft.com/en-us/microsoft-365/p/office-home-...
It's like the most trivial thing to change
> 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.)
The article actually goes into that in quite a bit of detail about that.
I've heard it's pretty good for fixing video playback/rendering (e.g. cutscene) issues if both the stable and the experimental branch of Proton can't make it work.
[1] https://github.com/GloriousEggroll/proton-ge-custom
I absolutely love my Ally running SteamOS. Incredible work by... everyone involved, really.
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.
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.
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#...
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.)
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://flightles...
https://web.archive.org/web/20250315200424/https://flightles...
https://web.archive.org/web/20250315200419/https://flightles...
> 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. :)
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
Jog on.
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.
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.
If I were more money motivated I’d probably be building CRUD apps too. I just like weird puzzles XD.
CRUDs do pay the bills.
So most of it.
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.
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.
Finally some embrace, extend, and extinguish love right back at Microsoft!
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
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.
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.
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
In the context of games, that will likely be Steam Runtime.
for example here is a 20 year old binary of the game mirrormagic that runs just fine on my modern fedora machine:
ok, there are some issues: the sound is not working, and the resolution does not scale. but there are no issues with linked libraries.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)
> 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.
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 ...
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)
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.
https://developer.apple.com/support/xcode/
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.
Either way my comment is intended as more humorous than truly insightful or prophetic.
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
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.
>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.
It's effective enough for it to be practically a solved problem now.
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.)
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?
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...
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.
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.
https://github.com/Alien4042x/Wine-NTsync-Userspace-macOS-ba...
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).
FYI the link to the Rosetta branch at the end 404s. Maybe change the point to the main repo?
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.
Now if we can just get some decent Nvidia drivers......
And then it never was more than half…
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.