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.)
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.
With Proton especially, which is WINE really optimized with all of the right options and a few other things, I play literally any game on linux and never worry about support. It hasn't steered me wrong yet in the last 3 or 4 years I think.
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
It's an unfair fear since architecturally Wine sits at the same position as the Win32 API on Windows, which also in the end merely uses the underlying native system calls. The only difference is that Linux aims to keep its system call interface stable.
Meanwhile I've been impressed with Wine since I discovered it. One of the few things that was keeping me from moving to Linux was MS Office suite. I struggled to get used to OpenOffice. And wine was able to run it. Sure I had to faff around with it, but I was just so impressed. I was telling all my family, but they just didn't get it.
Anyway, I later stopped using it because Google Docs and then later libreoffice was good enough. I still followed it, and I continued to be impressed by all the announcements.
The first time I seriously used wine it was to run Forscan (https://forscan.org/home.html) to interface with my car via OBD2 port. It quite literally just worked. Installed via the executable MSI installer, finished install, booted right up, and worked with the USB device.
I have been using Wine on Mac for fifteen years now since I moved to Mac for work. There's always been a couple Windows programs I just can't seem to replace fully, namely RegexBuddy, and I continue to run them in Wine to this day. Everything has gotten so much better as the years have gone on, that this is a perfectly acceptable solution.
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.
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.
I find it difficult to believe that someone with enough technical knowledge to run a Linux desktop for business purposes in 2026 would be reliant on the MS Office suite. Other people have given plenty of technical reasons for the difficulty. I don't think it’s a useful goal to get them running when practical alternatives like libreoffice exist.
Games really only usually rely on standardized libraries and APIs, whereas application software relies on system libraries to do things like paint their UI.
these apps are all like web browsers, and likely needlessly complicated due to patching the same codebase for so long. its MS afterall. there will be code in there that they themselves hardly understand.
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.
With this exact point in mind: I've recently written a pretty straight forward win32 c implementation of a utility with some context dependent window interactions and a tray icon to help monitor and facility reload of config file.
Is there any way I can use the Wine project to facilitate this compiling and running straight under x11/linux environment as a integrated project that doesn't require the end user to fiddle with Wine? I don't mind bundling shared code as needed. Help appreciated, I tried hard and failed at this endeavour priorly.
It’s astounding how badly Microsoft had to fumble their complete and unassailable monopoly on the standard video game runtime (ie Windows) for an upstart like Valve to be able to get WINE/Proton into a place where this is now possible.
The mind reels. They had the biggest moat in tech, and now small shops are easily tossing homemade ladders across the gap. AAA gaming is an industry larger than all of Hollywood, and Windows is no longer a critical component. This is incompetence on an unthinkable scale.
I wonder when and how Excel’s stranglehold will eventually be cracked, and if I will live to see it. Perhaps the new agentic universe will cause someone to finally make the Pixelmator of Excel.
There are huge swaths of workplaces that run on Google Docs. If you're using features of Excel and PowerPoint that doesn't work on Docs (except maybe fonts), it might be fair to say you're the one with the incompatible doc these days. K-12 education would be one such world.
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 spent my entire college career doing consulting for a company that worked on Wine since Wine was part of its commercial offering.
The work is not boring (it's fascinating!) but completely thankless. The documentation on MSDN was (and I'm guessing still is) complete shit, and most of the APIs are undocumented. Random fixes would have knock on effects. I contributed a bit to some cases on a bug open since the 90s, and since I'm still on the list, I still get messages about it!
AI unreliability aside, Microsoft suing the hell out of them was always a concern. They do clean room reimplementation to insulate themselves from legal risks as much as possible, another incentive is not what anyone wants.
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.)
Having done a multi targeted project in the 2005 range. I can tell you. The APIs that both systems provide are quite expansive and do quite a bit. However there is a mismatch on details and gaps. In this case the NT mutex system is 'there' in linux however the way it works is subtly different. You have to basically emulate waitforxxxxxxobject set of windows calls. Getting that right and performant can be quite a challenge.
My particular challenge was similar in around how threads were created destroyed and signals between them (such as mutex). We ended up making our own wrappers to insure the different platforms acted the same. Even something simple as just moving between two supposedly 'same' linux distros could be different depending on what the ODM did to their packages and supported libs. Having a dedicated linux object that acts exactly like the windows one would have made that code much simpler to do.
Another place where there is a huge impedance mismatch is in the permission system. In many ways the VMS/NT way is wildly detailed. Linux can do that but you have to emulate it or use it directly and hope you get it right on both sides. There are several places where windows/linux have the same functionality but the APIs are different enough that multi platform support is kinda awful to do.
More or less Wine + some experimental patches not yet I twgrated in mainstream wine + a buch of DirectX translation libraries + close steam integration.
Read the last sentence in that paragraph, those numbers are a bit disingenuous:
> Those benchmarks compare Wine NTSYNC against upstream vanilla Wine, which means there's no fsync or esync either. Gamers who use fsync are not going to see such a leap in performance in most games.
Steam devs if you are reading this: add a checkbox on your checkout screen that will allow me to donate 10% or a flat amount with each purchase, that will go directly to your upstream opensource dependencies like Wine & friends. I would add money to each purchase without blinking to support these people and I think the correct place for this is at the steam checkout screen, in the case for gamers.
This is a nice idea, but how do you follow through in practice? Who decides what counts as an "upstream dependency", where do you draw the line? Is the Linux kernel included? Are desktop environments included? How do you decide how much of the pot goes to each project, does curl get an equal amount to Wine? Why/why not?
As I said, it's a nice idea but I have a feeling the complexity behind making this work well is what might have kept them from doing it.
So the steam devs can most likely produce a finite list of all their dependencies. They can then take a day or two to score each one with a weight. Then they use the weights to determine how to split the funds. Or they can have an open source champion person internally that takes care of relationships with opensource projects and can release funds to them as needed. Point is, lets say they accumulate $1M/year this way, it is that person's responsibility to distribute it fully back out to the community. Obviously try to keep it super simple & transparent. They can even ask game developers each quarter who they should think need money or which problems were solved well for them this round, as an extra layer of input.
When it comes to Wine, aren't they already doing this? Steam develops Proton in cooperation with CodeWeavers, who are the main sponsors of Wine, and parts of that work is upstreamed to the Wine project. The NTSYNC patch from what I can tell was also submitted by a CodeWeavers employee, so it doesn't seem far-fetched to say that Steam probably contributed to making this happen in Wine.
There are many other open source projects that gets used that never sees the spotlight like Wine does, but they are crucial too. Think audio codecs & processing, compression libs, networking libs, even sqlite. Our society depends on these projects too but there are too much friction for normal people to contribute to them (if they are even aware). Steam checkout is a low friction surface where normal people spend time. A small optional checkbox at the bottom with a two sentence explanation or link to a blog post to explain where the money goes, will add minimal new friction while giving people the opportunity to contribute to something meaningful. I think many gamers (esp adult ones) knows what open source means and they will actually contribute now & then. Fund allocations must be transparent (crucial!) so people can see where the money went.
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.
Unless you are running an ancient LTS distribution, you at least have fsync. But then also recognize, with the ancient LTS distribution not carrying any enhancements for the last few years, your drivers are also out of date and games will play terribly for unrelated reasons.
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.
> 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.
That was all nice and good for a while, but the times are ending.
I suspect there will still be a human involved in the production of software, but it will be domain experts, not CRUd monkeys who picked up just enough domain knowledge to be dangerous.
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
Yeah exactly. High-level people think the low-level stuff is magic, and us from the other side think the high-level stuff is magic (how can you handle all that complexity?...)
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.
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 may be surprised by how much easier it is to dump the framework/stack and just write it from scratch. I say this because I too work on compilers and have a crud app as a personal project. The first versions were a nightmare in various frameworks and since I switched to a C++ backend / vanilla .js frontend it has been incredibly easy to write.
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.
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.
I am a normal web dev / CRUD app coder. All of this isn't beyond your ability.
Every so often I hit a problem that requires me to go all the way down to the OS level and find out what is going wrong or into the core framework and you find out that most of the code is actually less complex, better documented and clearer than a lot of the garbage bespoke applications you have to deal with at the higher levels.
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.
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.
Plenty of business apps don't really ask for much more than that, and those are the CRUD apps. They're not particularly challenging to write, nor is it very interesting to do so.
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.
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!
I agree with this take. Wine/Proton might become something akin to a runtime for games, running on many platforms and consoles. This means devs might stop targeting windows directly, but rather they target wine and you'll need that for your games on Windows.
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
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.
Wine has always beem a bandage not a final thing. Something to drive exactly this transition to better. Through wine ive been able to transition many colleagues accross because software they need will work as they expect it to in linux and everything elese is an arcane mystery to them anyway. This means one less network effect contributing win user. Most also experience a massive jump in tech literacy as a result of the move, since a system that doesn't wall you out at every step lets you passively learn more.
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.
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
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.
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 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.
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 I'm not mistaken, 16-bit x86 software cannot naively run in 64-bit mode anyways. It requires an emulator, like DosBox. Wine uses WineVDM. CPU-heavy 16-bit programs, or programs that are sensitive to timing, can be noticeably slower.
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.
If you really / actually want Linux and Linux Gaming to really take off, contribute with whatever helps to get Office 365 running in Linux without a VM.
Like it or not, the business world runs on Office.
I have quite a few machines under my direction, and I would drop Windows on every single one of them for employees that have never used Linux in their lives if I could be assured that they had Office and Teams.
I'm not an heavy o365 user but i'm almost happy on Debian KDE with thunderbird 148[0] (email only), teams-for-linux[1] (chat/calendar/whatever), Onedrive[2] and webdav (sharepoint)[3]. Libreoffice/Onlyoffice for documents.
[3] Store the SP cookie via konqueror visiting the SP site, then open it in dolphin via "webdavs://CORP.sharepoint.com/sites/SITE/Shared Documents/" (sometimes the cookie is very short-lived)
I tried very hard to make something similar work for a couple of months - Mint, teams-for-linux (which is great, actually!), web-apps for everything else.
The main problem is Word - for the documents I regularly work with professionally (large, complex, collaboratively-edited) the web-app is just not feature complete and sometimes struggles to cope.
Also, FWIW, the web Powerpoint is an awful experience.
After a brief flirtation with a virtual machine for Windows and Office (nah) I had to take a step back from Linux and use a Mac again.
I'd consider using it as Windows replacement. Exclusively Windows, as I don't care for the Linux applications, or anything Linux, at all. I don't enjoy being an admin, and the system is more stable without package management. Linux is a fossil from the age of the admin, best used today to emulate Windows, just like it runs under Android, as a HAL. If so, 2026 could be the year of the Linux desktop!
ReactOS is always almost there.. except it doesn't quite get there; same goes for Wine, as they have a lot in common?
I don't know if it is. Most businesses seem to use the web-based Office365 interface now, rather than native Office.
I expect the biggest reasons businesses use Windows these days are momentum, and lower support costs (Linux is still less reliably than Windows on real laptop hardware).
I work in an area where large heavy collaborative Word documents are very commonplace.
I've tried very much to make this work on Linux with the web apps, but they're just not good enough - not feature complete, and quite slow and clunky compared to the native equivalent.
I don’t think so. Windows is very easy to administer compared to both, Linux and Mac. There is also a compliance part that MS makes easier, though it’s a bit beyond what I really know.
If any Wine devs are reading this, I'd love to see a talk on this topic at the 2026 Carolina Code Conference. Call for Speakers is open until March 31st.
> This 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.
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).
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
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.
I would happily pay even a subscription to Wine, if they manage to get Lightroom running smoothly. So far I need to run VM or use a Mac just to do that.
CrossOver support of Lightroom is just as bad a wine... Realistically it will take $20-50k of dev work to make it work (and some other apps as a side effect).
This is awesome news. One application I'd love to see run in Linux is Solidworks. Is there any interest in this, what would be the most effective way to support it financially, and how big a donation do you think it would take to achieve extremely good results? (Or will it forever be stuck in VM's using passthrough GPU's?)
I predict a massive uptick in linux switchover as soon as installation and activation of some newer ms-office versions (2019, 2021 or 2024) become possible. I think 2019 was the first that shipped with a full fledged power query.
In my experience, as of now the one that works best and seamlessly is the 20 year old office 2007.
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]
I wonder if having a /dev/ntsync device could make it easier for game devs to compile their games for linux in the first place, instead of having to use wine. There may be other windows specific dependencies though, but this is one less right?
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 hope Photoshop runs in the Linux VM introduced with Android 16, so I can stop carrying a laptop to edit photos and bring just a 0.5kg monitor instead.
I know that Wine devs are doing most of the hard works but also Valve team for doing the last mile: pushing for better UX, faster patches, pushing adoption (with their Deck device), etc...
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.
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.
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.
> Wine 11 is different. This isn't just another yearly release with a few hundred bug fixes and some compatibility tweaks. It represents a huge number of changes and bug fixes.
What's the point of being a "journalist", when your job is to write words and instead a machine has written them? What is the point of such a "journalist"?
P.S. I am assuming "Lead Technical Editor" falls under the umbrella of "journalist" in some sense
I've been writing for nearly a decade, and I can assure you, all of this is human written. I've long been writing about the Linux kernel where it's been relevant to my coverage, and there are articles under my name talking about low-level technical aspects in drivers and kernels from as far back as 2017.
I get that it's hard to know what to trust out there given that Dead Internet Theory is beginning to feel like a reality, but comments like this can be quite upsetting after spending days researching and writing an article like this. I totally get criticism of the article itself, and I'm fine with that, but it feels as if people are too quick to jump on the "must be written by AI" bandwagon. I receive it, my colleagues receive it, and for the people who I know put in so much effort into their work, it can be upsetting to them as well.
As was mentioned in another thread, there were actually a couple of typos in this article when it went live. I cleaned those up once they were pointed out, but AI doesn't make typos. I get it to an extent; hostility and accusations of all kinds have been levied at writers for the years and years I've been in this industry writing long-form content and analysis. But with the proliferation of AI, that hostility has really ramped up over the last couple of years.
Apologies if my post hurt your feelings and I appreciate you taking the time to respond. The writing style in the piece I quoted looked very AI driven to me, that's why I said what I said.
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.)
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.
52 replies →
With Proton especially, which is WINE really optimized with all of the right options and a few other things, I play literally any game on linux and never worry about support. It hasn't steered me wrong yet in the last 3 or 4 years I think.
1 reply →
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
9 replies →
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.
It's an unfair fear since architecturally Wine sits at the same position as the Win32 API on Windows, which also in the end merely uses the underlying native system calls. The only difference is that Linux aims to keep its system call interface stable.
5 replies →
Meanwhile I've been impressed with Wine since I discovered it. One of the few things that was keeping me from moving to Linux was MS Office suite. I struggled to get used to OpenOffice. And wine was able to run it. Sure I had to faff around with it, but I was just so impressed. I was telling all my family, but they just didn't get it.
Anyway, I later stopped using it because Google Docs and then later libreoffice was good enough. I still followed it, and I continued to be impressed by all the announcements.
The first time I seriously used wine it was to run Forscan (https://forscan.org/home.html) to interface with my car via OBD2 port. It quite literally just worked. Installed via the executable MSI installer, finished install, booted right up, and worked with the USB device.
I have been using Wine on Mac for fifteen years now since I moved to Mac for work. There's always been a couple Windows programs I just can't seem to replace fully, namely RegexBuddy, and I continue to run them in Wine to this day. Everything has gotten so much better as the years have gone on, that this is a perfectly acceptable solution.
[flagged]
5 replies →
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.
> 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.
58 replies →
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.
4 replies →
I find it difficult to believe that someone with enough technical knowledge to run a Linux desktop for business purposes in 2026 would be reliant on the MS Office suite. Other people have given plenty of technical reasons for the difficulty. I don't think it’s a useful goal to get them running when practical alternatives like libreoffice exist.
1 reply →
I don't know that they are. It's just there's more incentive to port stuff that has no direct alternative.
Games really only usually rely on standardized libraries and APIs, whereas application software relies on system libraries to do things like paint their UI.
these apps are all like web browsers, and likely needlessly complicated due to patching the same codebase for so long. its MS afterall. there will be code in there that they themselves hardly understand.
Although running Microsoft web apps are getting better.
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.
With this exact point in mind: I've recently written a pretty straight forward win32 c implementation of a utility with some context dependent window interactions and a tray icon to help monitor and facility reload of config file.
Is there any way I can use the Wine project to facilitate this compiling and running straight under x11/linux environment as a integrated project that doesn't require the end user to fiddle with Wine? I don't mind bundling shared code as needed. Help appreciated, I tried hard and failed at this endeavour priorly.
3 replies →
It’s astounding how badly Microsoft had to fumble their complete and unassailable monopoly on the standard video game runtime (ie Windows) for an upstart like Valve to be able to get WINE/Proton into a place where this is now possible.
The mind reels. They had the biggest moat in tech, and now small shops are easily tossing homemade ladders across the gap. AAA gaming is an industry larger than all of Hollywood, and Windows is no longer a critical component. This is incompetence on an unthinkable scale.
I wonder when and how Excel’s stranglehold will eventually be cracked, and if I will live to see it. Perhaps the new agentic universe will cause someone to finally make the Pixelmator of Excel.
There are huge swaths of workplaces that run on Google Docs. If you're using features of Excel and PowerPoint that doesn't work on Docs (except maybe fonts), it might be fair to say you're the one with the incompatible doc these days. K-12 education would be one such world.
2 replies →
ReactOS also deserves an honorary mention. A lot of knowledge from that project feeds into Wine.
And vice-versa. It's pretty interesting that the two projects haven't kind of merged despite all the collaboration.
4 replies →
I simply wouldn’t have the patience to do what Elizabeth did, for a month, much less years. Really really impressive
I guess the silver lining is that the Windows ABI is extremely stable
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 was rewriting an old game of mine using SDL2 for release on Steam—had struggled with getting a build target for Linux/Steam Deck.
Man, Wine just worked and I confess I copped out and just delivered MacOS and Windows targets.
There was a time when WINE was iffy. At best.
It’s gotten good and reliable.
Commendations to contributors!
Yes, Wine is truly a miracle. Once full support for Office is achieved, we should expect huge uptick in Linux adoption.
> full support for office
does microsoft still sell office?
8 replies →
I wouldn't put it past Microsoft to suddenly add "features" that break said support.
1 reply →
Ny that time office will be cloud only.
That's not boring at all. A lot of the works done in Wine can be fed back to ReactOS
I spent my entire college career doing consulting for a company that worked on Wine since Wine was part of its commercial offering.
The work is not boring (it's fascinating!) but completely thankless. The documentation on MSDN was (and I'm guessing still is) complete shit, and most of the APIs are undocumented. Random fixes would have knock on effects. I contributed a bit to some cases on a bug open since the 90s, and since I'm still on the list, I still get messages about it!
With AI, you can automate all the grunt work.
AI unreliability aside, Microsoft suing the hell out of them was always a concern. They do clean room reimplementation to insulate themselves from legal risks as much as possible, another incentive is not what anyone wants.
1 reply →
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.
Wine configuration -> Drives -> Remove
It's like the most trivial thing to change
1 reply →
> 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.
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.)
Though like the article mentions, fsync doesn't work out of the box (requiring kernel patches).
> 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.
1 reply →
Do they have any other usecase behind Wine? My guess would be MS SQL server, but is that correct?
4 replies →
Having done a multi targeted project in the 2005 range. I can tell you. The APIs that both systems provide are quite expansive and do quite a bit. However there is a mismatch on details and gaps. In this case the NT mutex system is 'there' in linux however the way it works is subtly different. You have to basically emulate waitforxxxxxxobject set of windows calls. Getting that right and performant can be quite a challenge.
My particular challenge was similar in around how threads were created destroyed and signals between them (such as mutex). We ended up making our own wrappers to insure the different platforms acted the same. Even something simple as just moving between two supposedly 'same' linux distros could be different depending on what the ODM did to their packages and supported libs. Having a dedicated linux object that acts exactly like the windows one would have made that code much simpler to do.
Another place where there is a huge impedance mismatch is in the permission system. In many ways the VMS/NT way is wildly detailed. Linux can do that but you have to emulate it or use it directly and hope you get it right on both sides. There are several places where windows/linux have the same functionality but the APIs are different enough that multi platform support is kinda awful to do.
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?
More or less Wine + some experimental patches not yet I twgrated in mainstream wine + a buch of DirectX translation libraries + close steam integration.
5 replies →
It's a distribution of Wine with some extra stuff added, importantly DXVK (directx => vulkan layer) and a lot of game specific workarounds.
* when not using esync nor fsync
Read the last sentence in that paragraph, those numbers are a bit disingenuous:
> Those benchmarks compare Wine NTSYNC against upstream vanilla Wine, which means there's no fsync or esync either. Gamers who use fsync are not going to see such a leap in performance in most games.
That makes Wine on Linux even more amazing.
It means these games were already running well in Linux and even better now.
Steam devs if you are reading this: add a checkbox on your checkout screen that will allow me to donate 10% or a flat amount with each purchase, that will go directly to your upstream opensource dependencies like Wine & friends. I would add money to each purchase without blinking to support these people and I think the correct place for this is at the steam checkout screen, in the case for gamers.
This is a nice idea, but how do you follow through in practice? Who decides what counts as an "upstream dependency", where do you draw the line? Is the Linux kernel included? Are desktop environments included? How do you decide how much of the pot goes to each project, does curl get an equal amount to Wine? Why/why not?
As I said, it's a nice idea but I have a feeling the complexity behind making this work well is what might have kept them from doing it.
So the steam devs can most likely produce a finite list of all their dependencies. They can then take a day or two to score each one with a weight. Then they use the weights to determine how to split the funds. Or they can have an open source champion person internally that takes care of relationships with opensource projects and can release funds to them as needed. Point is, lets say they accumulate $1M/year this way, it is that person's responsibility to distribute it fully back out to the community. Obviously try to keep it super simple & transparent. They can even ask game developers each quarter who they should think need money or which problems were solved well for them this round, as an extra layer of input.
4 replies →
It’s a nice idea, but why not donate directly?
https://www.winehq.org/donate
When it comes to Wine, aren't they already doing this? Steam develops Proton in cooperation with CodeWeavers, who are the main sponsors of Wine, and parts of that work is upstreamed to the Wine project. The NTSYNC patch from what I can tell was also submitted by a CodeWeavers employee, so it doesn't seem far-fetched to say that Steam probably contributed to making this happen in Wine.
There are many other open source projects that gets used that never sees the spotlight like Wine does, but they are crucial too. Think audio codecs & processing, compression libs, networking libs, even sqlite. Our society depends on these projects too but there are too much friction for normal people to contribute to them (if they are even aware). Steam checkout is a low friction surface where normal people spend time. A small optional checkbox at the bottom with a two sentence explanation or link to a blog post to explain where the money goes, will add minimal new friction while giving people the opportunity to contribute to something meaningful. I think many gamers (esp adult ones) knows what open source means and they will actually contribute now & then. Fund allocations must be transparent (crucial!) so people can see where the money went.
1 reply →
might as well just buy Crossover to support Wine
Steam and most other nontrivial applications use other open source components internally. Those need funding as well.
They can take it from the current 30% cut
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.
>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.
Unless you are running an ancient LTS distribution, you at least have fsync. But then also recognize, with the ancient LTS distribution not carrying any enhancements for the last few years, your drivers are also out of date and games will play terribly for unrelated reasons.
1 reply →
Most people? What mainstream Linux distros ship without fsync or esync support?
10 replies →
The article says fsync uses futexes which are a completely standard kernel feature.
1 reply →
> usually in the lower single percentage range
Is it worth to compare Wayland vs X11?
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.
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.
> He called it his paid vacation.
As a fellow CRUD writer you're kinda seconding the OP's point here...
Personally I say oh well, some people are smarter and/or harder working than me. Now watch this drive -
1 reply →
> 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.
That was all nice and good for a while, but the times are ending.
I suspect there will still be a human involved in the production of software, but it will be domain experts, not CRUd monkeys who picked up just enough domain knowledge to be dangerous.
3 replies →
ai slop
3 replies →
All good. I tell people how to add another mailbox to their Outlook, "click here, now there". Not glorious. Necessary anyways.
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
4 replies →
Yeah exactly. High-level people think the low-level stuff is magic, and us from the other side think the high-level stuff is magic (how can you handle all that complexity?...)
3 replies →
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.
They don't. The "simplicity" of using a "high-level" framework for someone who bit-shifts for a living is almost comical.
16 replies →
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 may be surprised by how much easier it is to dump the framework/stack and just write it from scratch. I say this because I too work on compilers and have a crud app as a personal project. The first versions were a nightmare in various frameworks and since I switched to a C++ backend / vanilla .js frontend it has been incredibly easy to write.
2 replies →
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.
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.
Play with low level things. It'll help you in your daily job in ways you do not yet imagine. Start here: nandgame.com
Don't feel too bad - I had to Google what CRUD means. :D
I am a normal web dev / CRUD app coder. All of this isn't beyond your ability.
Every so often I hit a problem that requires me to go all the way down to the OS level and find out what is going wrong or into the core framework and you find out that most of the code is actually less complex, better documented and clearer than a lot of the garbage bespoke applications you have to deal with at the higher levels.
Same. I feel like a plumber compared to real engineers.
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.
Engineers & architects leave a lot of detail out of their designs, relying on the plumbers and other trades to figure out the Right Thing. (-:
Engineers feel like plumbers compared to the plumbers
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.
CRUD = Create, Read, Update, Delete
Plenty of business apps don't really ask for much more than that, and those are the CRUD apps. They're not particularly challenging to write, nor is it very interesting to do so.
>People are dealing with such low level things, while i'm outta here building simple CRUDs.
CRUDs do pay the bills.
If it's any consolation I can out-imposter you: lately I've been mostly reviewing LLM-generated code.
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.
[dead]
[dead]
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.
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.
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.
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.
I wouldn't be surprised if Wine eventually becomes more stable than Windows.
26 replies →
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!
1 reply →
Ever since Proton came along, it has been a quiet agreement that Win32 APIs are the best target for Linux support.
Building against the Steam runtime containers seems like the other route, which also gets you more stability.
I agree with this take. Wine/Proton might become something akin to a runtime for games, running on many platforms and consoles. This means devs might stop targeting windows directly, but rather they target wine and you'll need that for your games on Windows.
Valve nudges developers to ship/support their "one best version" of a game, and trust compatibility layers to make it work for everyone else.
For x86, that's Windows. For mobile/VR, it's Android.
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
29 replies →
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.
This is the very definition of "a good problem to have."
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.
Unlikely. Games need a stable ABI and Win32 is the only stable ABI on Linux.
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
5 replies →
People who keep parroting this clearly have no experience of gaming on linux.
8 replies →
Quiet the other way around. Wine being good will reduce incentives for game studio to produce native Linux ports.
Wine has always beem a bandage not a final thing. Something to drive exactly this transition to better. Through wine ive been able to transition many colleagues accross because software they need will work as they expect it to in linux and everything elese is an arcane mystery to them anyway. This means one less network effect contributing win user. Most also experience a massive jump in tech literacy as a result of the move, since a system that doesn't wall you out at every step lets you passively learn more.
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.
In many cases for game devs/publishers "supporting Linux" now means making sure the Windows build runs well under Proton.
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
There always will be old games that will never be ported to Linux.
It's interesting when old Windows games run better in Wine than in actual Windows 10/11.
It's even more interesting when the latest Windows games run better in Wine than in actual Windows 10/11.
If you game/app runs on Wine, doesn't that reduce the pressure to develop a Linux port?
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.
1 reply →
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.
A solution to itself
Gotta get there somehow.
OS/2 part deux
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.)
[flagged]
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....
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?
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.
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 I'm not mistaken, 16-bit x86 software cannot naively run in 64-bit mode anyways. It requires an emulator, like DosBox. Wine uses WineVDM. CPU-heavy 16-bit programs, or programs that are sensitive to timing, can be noticeably slower.
The WoW64 including 16 bit support is actually pretty big. Microsoft dropped it years ago.
32 bit game with 16 bit installer has a lot of examples, to the point that Windows has workarounds for common installers.
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.
Entirely.
If you really / actually want Linux and Linux Gaming to really take off, contribute with whatever helps to get Office 365 running in Linux without a VM.
Like it or not, the business world runs on Office.
I have quite a few machines under my direction, and I would drop Windows on every single one of them for employees that have never used Linux in their lives if I could be assured that they had Office and Teams.
> Like it or not, the business world runs on Office.
Maybe if EU requires local governments to use LibreOffice (or other OSS alternatives like MijnBureau) companies will follow.
https://www.libreoffice.org/discover/who-uses-libreoffice/
https://minbzk.github.io/mijn-bureau/
I'm not an heavy o365 user but i'm almost happy on Debian KDE with thunderbird 148[0] (email only), teams-for-linux[1] (chat/calendar/whatever), Onedrive[2] and webdav (sharepoint)[3]. Libreoffice/Onlyoffice for documents.
[0] https://blog.thunderbird.net/2025/11/thunderbird-adds-native...
[1] https://github.com/IsmaelMartinez/teams-for-linux
[2] https://github.com/abraunegg/onedrive + https://github.com/bpozdena/OneDriveGUI
[3] Store the SP cookie via konqueror visiting the SP site, then open it in dolphin via "webdavs://CORP.sharepoint.com/sites/SITE/Shared Documents/" (sometimes the cookie is very short-lived)
I tried very hard to make something similar work for a couple of months - Mint, teams-for-linux (which is great, actually!), web-apps for everything else.
The main problem is Word - for the documents I regularly work with professionally (large, complex, collaboratively-edited) the web-app is just not feature complete and sometimes struggles to cope.
Also, FWIW, the web Powerpoint is an awful experience.
After a brief flirtation with a virtual machine for Windows and Office (nah) I had to take a step back from Linux and use a Mac again.
I'd consider using it as Windows replacement. Exclusively Windows, as I don't care for the Linux applications, or anything Linux, at all. I don't enjoy being an admin, and the system is more stable without package management. Linux is a fossil from the age of the admin, best used today to emulate Windows, just like it runs under Android, as a HAL. If so, 2026 could be the year of the Linux desktop!
ReactOS is always almost there.. except it doesn't quite get there; same goes for Wine, as they have a lot in common?
I don't know if it is. Most businesses seem to use the web-based Office365 interface now, rather than native Office.
I expect the biggest reasons businesses use Windows these days are momentum, and lower support costs (Linux is still less reliably than Windows on real laptop hardware).
I work in an area where large heavy collaborative Word documents are very commonplace.
I've tried very much to make this work on Linux with the web apps, but they're just not good enough - not feature complete, and quite slow and clunky compared to the native equivalent.
I don’t think so. Windows is very easy to administer compared to both, Linux and Mac. There is also a compliance part that MS makes easier, though it’s a bit beyond what I really know.
If any Wine devs are reading this, I'd love to see a talk on this topic at the 2026 Carolina Code Conference. Call for Speakers is open until March 31st.
> This 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.
it seems if you want the same on macOS, this is the place to contribute:
https://github.com/Alien4042x/Wine-NTsync-Userspace-macOS-ba...
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.
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).
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.
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.
[1] https://github.com/torvalds/linux/blob/master/drivers/misc/n...
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.
1 reply →
> 3. WHY IT CAN'T BE DONE WITH EXISTING TOOLS
https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5a...
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
Here's a link to try it
https://www.codeweavers.com/crossover/download
Flagged as advertisement
What advertisement?
Codeweavers is literally the company behind Wine. Without them project would never reach point where it is now.
Codeweavers developers historically been authors of 2/3 (and likely even more in past) commits in Wine.
Uh?
CodeWeavers : Wine :: IBM/RedHat : Fedora
awesome, finally wine is getting proper ntsync support... and i reckon wow64 will let me run so many old games...
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.
Yeah I was wondering if some native Linux apps might want to use it, since it is clearly useful and hard to emulate.
1 reply →
This comes up often, but what can it do that poll can't?
2 replies →
I would happily pay even a subscription to Wine, if they manage to get Lightroom running smoothly. So far I need to run VM or use a Mac just to do that.
Codeweavers.com
They'll take your money, and you'll be contributing to wine.
It looks like they do commercial wine projects. Might cost more than a coffee a day tho!
CrossOver support of Lightroom is just as bad a wine... Realistically it will take $20-50k of dev work to make it work (and some other apps as a side effect).
I would pay if I can use Clip Studio Paint without lag. In fact, I will try another time this easter. If works, I will need to donate.
This is awesome news. One application I'd love to see run in Linux is Solidworks. Is there any interest in this, what would be the most effective way to support it financially, and how big a donation do you think it would take to achieve extremely good results? (Or will it forever be stuck in VM's using passthrough GPU's?)
I'd rather they focus on productivity apps than games. Linux has enough toxic users as it is. I'll praise wine when I can install 12yo office 2014
[dead]
I predict a massive uptick in linux switchover as soon as installation and activation of some newer ms-office versions (2019, 2021 or 2024) become possible. I think 2019 was the first that shipped with a full fledged power query.
In my experience, as of now the one that works best and seamlessly is the 20 year old office 2007.
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 someone can get the last decent ver. of Excel and Word running on Wine, that would be awesome
I wish competitive shooters (or rather their anti-cheats) would run on Linux. Only reason left to use Windows.
I wonder if having a /dev/ntsync device could make it easier for game devs to compile their games for linux in the first place, instead of having to use wine. There may be other windows specific dependencies though, but this is one less right?
Does it finally support visual studio?
the NTSYNC change is for video games, doesn't help VS
Yes, true. And the 64bit support may help visual studio, right?
If someone is interested in hearing the author Elizabeth Figura's views on Wine and Proton: https://www.youtube.com/watch?v=ZNBKTolL5oQ
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.
At least for the last decade Visual Studio and Photoshop ran just fine on wine.
I hope Photoshop runs in the Linux VM introduced with Android 16, so I can stop carrying a laptop to edit photos and bring just a 0.5kg monitor instead.
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?
I know that Wine devs are doing most of the hard works but also Valve team for doing the last mile: pushing for better UX, faster patches, pushing adoption (with their Deck device), etc...
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.
Running most of my VSTs with wine + yabridge. Amazing that transcription layer/emulation software end up having less issues than running shit native.
so apparently it is Proton GE 10.9 from July'25 adding ntsync support [0].
I'm playing on wine now for several years now, my deepest respect for the developers involved. Thank you!
[0]: https://www.linuxcompatible.org/story/geproton109-released/
“And because Proton, SteamOS, and every downstream project builds on top of Wine, those gains trickle down to everyone.”
the gains would trickle up, no?
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......
What's wrong with the Nvidia drivers for Linux?
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.
5 replies →
In practically every benchmark the Linux Nvidia drivers notably underperform compared to the windows driver.
Anybody know if NTSYNC support is why the Chrome OS team moved away from native Steam support?
Wine removed 32-bit support, breaking 90% of programs people used it for.
source? they actually just added 16bit support. Something not even Windows support anymore.
Not that it really matters, but does this article read as LLM authored to anyone else?
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.
I had to close 3 ads before even half my screen was the article
And then it never was more than half…
I am trying to read this article on my phone without an ad blocker, and it is an impossible challenge.
Ads keeps loading and unloading, causing the page to jump around, and lose track of what I was reading.
The article is really interesting, but I am actively getting frustrated with my phone.
If we could get Proton for Mac now, it would be amazing.
BattleEye kernel module in 3 2...
For someone gaming on linux, is proton or wine currently ahead on the virtualization side?
Can we finally ditch windows ?
[dead]
[dead]
[flagged]
Why?
[flagged]
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.
[flagged]
> Wine 11 is different. This isn't just another yearly release with a few hundred bug fixes and some compatibility tweaks. It represents a huge number of changes and bug fixes.
What's the point of being a "journalist", when your job is to write words and instead a machine has written them? What is the point of such a "journalist"?
P.S. I am assuming "Lead Technical Editor" falls under the umbrella of "journalist" in some sense
Hey, article author here!
I've been writing for nearly a decade, and I can assure you, all of this is human written. I've long been writing about the Linux kernel where it's been relevant to my coverage, and there are articles under my name talking about low-level technical aspects in drivers and kernels from as far back as 2017.
I get that it's hard to know what to trust out there given that Dead Internet Theory is beginning to feel like a reality, but comments like this can be quite upsetting after spending days researching and writing an article like this. I totally get criticism of the article itself, and I'm fine with that, but it feels as if people are too quick to jump on the "must be written by AI" bandwagon. I receive it, my colleagues receive it, and for the people who I know put in so much effort into their work, it can be upsetting to them as well.
As was mentioned in another thread, there were actually a couple of typos in this article when it went live. I cleaned those up once they were pointed out, but AI doesn't make typos. I get it to an extent; hostility and accusations of all kinds have been levied at writers for the years and years I've been in this industry writing long-form content and analysis. But with the proliferation of AI, that hostility has really ramped up over the last couple of years.
Apologies if my post hurt your feelings and I appreciate you taking the time to respond. The writing style in the piece I quoted looked very AI driven to me, that's why I said what I said.