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.
Space Marine 2 was the latest one for me, but Steam is great at refunds if you do it quickly enough.
It actually gives a far better user experience for games like Battlefield 6, because on Linux they just don't work at all. Try it for yourself - it won't even start!
By contrast if you run Battlefield 6 on Windows, eventually you'll end up playing it, and you'll wish you hadn't. It's a shitty buggy mess and you'll hate it.
So, notch up another score for Linux!
Also, I assume some Windows version jumps didn't make things easy for Wine either lol
Yes, there was “the list” but there was no context and it was hard to replicate settings.
I think everyone tried running a contemporary version of Office and Photoshop, saw the installer spit out cryptic messages and just gave up. Enough time has passed with enough work done, and Wine now supports/getting to support the software we wanted all along.
Also, does anyone remember the rumours that OS X was going to run Windows applications?
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.
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?
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 don't know how much of their business it is today, but CodeWeavers spent their first decade or so supporting only non-game applications. Their product Crossover was originally Crossover Office because it was optimized around productivity applications.
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.
I believe that's what Winelib is for: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-G...
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.
[0] https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...
⸻
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.
Man, Wine just worked and I confess I copped out and just delivered MacOS and Windows targets.
It’s gotten good and reliable.
Commendations to contributors!
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-...
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!
> 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.
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.
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.
I absolutely love my Ally running SteamOS. Incredible work by... everyone involved, really.
> 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.
It means these games were already running well in Linux and even better now.
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.
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.
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.)
Is it worth to compare Wayland vs X11?
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 -
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.
Looking at your comments however, while probably not AI, they're still not helpful.
First time I've been accused of AI.
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
Most people know that there is a big difference between experience in something pretty easy vs mastery of something very difficult.
A rocket scientist acknowledges a concrete guy knows way more than he does about concrete, but also knows that doesn't make him a genius because it's easy enough to learn just being around it. Plus, the rocket scientist also knows that since he knows so little about concrete, he wouldn't even be able to judge if the guy is really a concrete genius or just saying things a real pro would label wrong.
Your example isn't that crazy, but still, you should realize your friend is just being nice.
Jog on.
If I were more money motivated I’d probably be building CRUD apps too. I just like weird puzzles XD.
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.
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.
CRUDs do pay the bills.
So most of it.
Finally some embrace, extend, and extinguish love right back at Microsoft!
For x86, that's Windows. For mobile/VR, it's Android.
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.
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.
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
In the end I gave up and just used proton on the windows .exe. Unbelievable. :(
Open source software also needs a stable ABI because:
a) i don't want to bother building it over and over (not everything is in my distro's repository, a ton of software has a stupid building process and not every new version is always better than the old versions)
b) a stable ABI implies a stable API and even if you have the source, it is a massive PITA to have to fix whatever stuff the program's dependencies broke to get it running, especially if you're not the developer who made it in the first place
c) as an extension to "b", a stable API also means more widely spread information/knowledge about it (people wont have to waste time learning how to do the same tasks in a slightly different way using a different API), thus much easier for people to contribute to software that use that API
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.)
FYI the link to the Rosetta branch at the end 404s. Maybe change the point to the main repo?
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.
Maybe if EU requires local governments to use LibreOffice (or other OSS alternatives like MijnBureau) companies will follow.
[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)
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.
ReactOS is always almost there.. except it doesn't quite get there; same goes for Wine, as they have a lot in common?
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'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.
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.
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).
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.
[1] https://lkml.org/lkml/2019/7/30/1399 [2] https://docs.kernel.org/userspace-api/ntsync.html
https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5a...
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.
CodeWeavers : Wine :: IBM/RedHat : Fedora
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.
There was also something about needing to back out if any of the reads fails to acquire, which also sounds nasty.
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!
In my experience, as of now the one that works best and seamlessly is the 20 year old office 2007.
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/
the gains would trickle up, no?
Now if we can just get some decent Nvidia drivers......
And then it never was more than half…
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.
Can we finally ditch windows ?
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.
