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.
Now if only Steam would add a checkbox on their checkout page to add 10% donation/tip that goes directly to their upstream opensource dependencies (like the Wine team), that would be amazing! I would add extra money on every purchase to support these people!
I'm in Africa, when I go to the steam deck page, it says it is not available in my country. Not interested in buying from a third party importer. So until then..
Requires PayPal or credit card. The suggestion was to pay with your Steam Wallet or whatever payment method already used when you buy a Proton-based game on Steam.
IMHO this supports the original point that payment via Steam would be an upgrade:
Sending cash to a postal address isn't low-effort nor low-risk.
Payment by cheque is something I have never done, nor would I know how to do it. I'd have to ask at my bank -- not low effort. I don't know if I'm an outlier here but I have never heard from any of my peers who ever did such a thing.
The same or even worse is true for international money orders. The whole concept of making a money transfer to a postal address is something I have never heard of. Where's the IBAN?
The Wine team is right to put even PayPal before all of these.
Yes, I do. It just means that you have to manually "recharge" your Steam wallet when it runs low. That's some effort, but it limits the possible damage if something goes wrong.
You always give 30% to Valve and their interests so far are aligned. Everything that's possible within the Steam ecosystem is available outside of it. Maybe things will change in the future, but I doubt we could be getting a better deal.
> if only Steam would add a checkbox on their checkout page to add 10% donation/tip that goes directly to their upstream opensource dependencies
Or how about instead of passing the cost off to users, Steam actually supports them from their own profits? After all, they are profiting from free work.
As far as I can tell, Valve makes significant contributions back to Wine via Proton development. Isn't that essentially them supporting their upstream dependencies with their own profits, by using some of those profits to pay people to contribute work to their open source dependencies?
Valve pays over a hundred open source developers to work on the various open source projects that they rely on so heavily, so yeah Valve's 30% of your Steam purchases is already contributing to these open-source projects (like Mesa, the Linux kernel, Wayland, etc.)
Forwarded donations are not tax-deductible (in the US); That's a lie that's been spread around the internet. If you give a company money with the express purpose of them forwarding it to someone else (the company acts as a "collection agent"), it's not their income or donation.
So it would be actually financially _better_ for Valve to donate a portion of their revenue and state "we will donate x% of the price to yy", as THEN it would be tax-deductible for them
It's not better, because being revenue and donated away and tax-deductible all cancels out. It's as if they never saw the money, just like forwarding it.
And even if it was, all "tax deductible" would mean is that they wouldn't have to pay taxes on that money. Which, you know, they don't get to spend. So it's kind of defacto tax deductible in the same sense that my friend's income is "tax deductible" for me, I guess.
A lot of people online have convinced themselves that "tax deductible" means that the government would refund you that dollar amount. That's a "tax credit"... If forwarded donations were a tax credit, then yes, rounding up is giving the company "free" money! But you're not.
I really is impressive. I wish publishers like EA and anti-cheat developers weren't so reluctant to support it. I hope Steam devices and SteamOS gain enough traction to force their hands.
Hate to be the one saying this, but that rootkit is there to prevent you from molesting/cheating other players. So its not an one-sided issue. It is unfortunate that the developers found no other way of fighting cheats, sure.
And by all means, if a game community is so toxic that it has to be policed by extreme measures, it is perhaps indeed better to avoid playing such a game altogether.
agreed. if a condition of attending an event was that I had to wear a chastity belt that prevented guests from raping each other, I'd think twice about attending alltogether.
I don’t care if my shooter game “community” is toxic. I don’t have any interaction with the “community” other than to try and virtually kill its members. I wish my chess app had anti-cheat, there are just some people who will cheat and any game is more fun if they can be prevented from playing.
Ironically the only way I would ever consider robust anti-cheet is if the game installed a seperate bootable Linux witch didn't have the encryption keys for my main partition.
Does windows make it easy to tell the installer wants to install kernel anti cheat? It used to pop up the generic binary "This application wants to change files on your computer" which could be installing in the protected "Program Files" or could be modifying anything.
I read the person I was responding to saying they avoided games with root kits for moral, not technical, reasons. So I assumed they were on Windows, and AFAIK, windows just offers binary "changes" permissions which covers anything from installing in the slightly protected Program Files directory to installing a rootkit. In other words, can they even detect they are about to install a root kit?
Wine doesn't emulate the NT kernel; Just the NT and Win32 userspace APIs. For example, Wine provides a `kernel32.dll` that maps API calls into the appropriate Linux ones. Anything kernel level is operating "below" Wine.
> and should be for most games that don't use kernel-level anticheat.
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.
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
The hype/performance mismatch was significant in the 2000s for Wine. I’m not sure if there was any actual use case aside from running obscure business software.
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?
I used WINE a lot in the 2000s, mostly for gaming. It was often pretty usable, but you often needed some hacky patches not suitable for inclusion in mainline. I played back then with Cedega and later CrossOver Games, but the games I played the most also had Mac ports so they had working OpenGL renderers.
My first memorable foray into Linux packaging was creating proper Ubuntu packages for builds of WINE that carried compatibility and performance patches for running Warcraft III and World of Warcraft.
Nowadays Proton is the distribution that includes such hacks where necessary, and there are lots of good options for managing per-game WINEPREFIXes including Wine itself. A lot of the UX around it has improved, and DirectX support has gotten really, really good.
But for me at least, WINE was genuinely useful as well as technically impressive even back then.
Also these apps changed, A lot of windows programs were simple executables and I remenber for a moment it was very popular for developers to write portable apps that were just a .exe that you ran,also excel and other programs worked fine, but then microsoft and others started to use msxis or whatever it's called and more complex executable files and it was not longer posible, and microsoft and adobe switched to a subscription based system.
I remember it being surprisingly decent for games back then. Then a lot of games moved to Steam, which made it way harder to run them in Wine. Of course there was later Proton for that, but not on Mac.
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.
win32 dates back to 1993. OP doesn't know Windows history. Maintaining backwards compatibility was always a huge priority for Microsoft, even if it couldn't be perfect.
If a program didn't work on a newer version of Windows, there's a good chance it was doing something unsupported.
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.
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.
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.
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.
Outlook is now basically an Electron app, they've deprecated the old desktop Outlook in favor of a port of the web app to desktop, so it's basically just Excel remaining.
Yeah, that's because Microsoft can see the writing on the wall. They don't want Windows to die, but they know the whole OS is at a point where it's probably inevitable that it will.
Developers don't want to use Windows anymore. They all want to run Linux because servers do. Ballmer was right about one thing: It was about the developers.
Microsoft can't compete with Chrome at the K-12 level. A Chromebook is a fraction of the cost at twice the runtime, so nobody is going to learn Windows growing up. There won't be a generation of new ready-trained Microsoft consumers every year.
And the average consumer? Oh, they're running an iPhone and maybe an iPad that's it. If Apple were really smart they'd have released an iPhone screencast dock, but Apple still thinks the iPhone doesn't need multiple user profiles. However, even with Apple's stupid behavior, they're losing their core consumer audience.
Steam is tired of Microsoft, too, so they're pushing for compatibility. Video games are either cross platform, console exclusive, or easy enough to emulate. If nVidia's graphics drivers weren't so proprietary, it wouldn't be nearly as difficult.
The big holdouts are the same people that kept COBOL a live programming language in the 21st century: The business office folks.
Microsoft has missed the boat on smartphones, tablets, budget laptops, smart TVs, video game consoles (which is a little surprising), server-side infrastructure, development, and now AI. Their market prospects right now are Millenials and older that don't want change, people who need exactly Excel or Outlook, and PC video gamers that aren't interested in change. Their best product is VS Code and it's free, their second best product (SQL Server) is pricing people out, and their third best product (.Net) is also free.
At this point I think they're mainly hoping Adobe doesn't jump ship.
If the Electron app is pure JS with no native extensions it can be doable. However, many Electron apps contain platform-specific js code, since features for stuff like Dock on Mac and Taskbar icons on Windows differ. Electron apps like Notion also contain native extensions - compiled C/C++/Objective-C code that are platform specific. For example in Notion, we use sqlite via better-sqlite3 (potentially replaceable since it’s open source, but will need more work than “just” repackaging js), but we also write our own native support libraries to use OS-specific APIs for microphone recording in meeting notes feature.
> Could it be possible to make the relatively new AI meeting notes feature to work?
> Right now I get the following error when I click the "start transcribing" button:
Error occurred in handler for 'notion:get-media-access-status': TypeError: s.systemPreferences.getMediaAccessStatus is not a function
at /usr/lib/notion-app/app.asar/.webpack/main/index.js:2:631015
at WebContents.<anonymous> (node:electron/js2c/browser_init:2:87444)
at WebContents.emit (node:events:524:28)
Not my area of expertise so I could be wrong but Electron apps just use Chromium underneath (which already works on linux), so in theory it should be easier to get them running on linux than a native Windows app
Electron is basically just a GUI framework. The application itself can be arbitrarily complicated, nothing stops you from building a Java + .NET + C++&COM app that includes three Windows Services that interfaces with the Electron runtime just for UI.
Having worked in non-swe enterprise for two decades I would argue that this is less true today than it was 10 years ago. It used to be that new hires would come with a basic knowledge of windows and office, but that's no longer the case. At the same time, you have things like Smartsheets and so on, which are more popular, at least with our employees, than Excel and everyone seems to hate Outlook these days. I don't think it was ever really the case though. What Microsoft sells to enterprise is governance, and they really don't have any competition in this area.
Being in the European energy sector we're naturally looking into how we can replace every US tech product with an EU/FOSS one. It's actually relatively easy to buy the 365 experience through consultants which will setup a NextCloud, Libre/Only Office, Proton and a teams replacement I can't for the life of me remember the name of. Beneath it there is a mix of Identity Management systems, often based around Keycloak, at least for now. It works, from what we've seen in Germany (specificlaly with their military) it's also possible to roll it out relatively quickly. It's all the "other" stuff that gets murky. There isn't a real alternative to AD/Entra, yet, from a governance perspective. There are great tech solutions which does the same thing, but they require a lot of IT man hours. Something the public sector is always going to be more willing to deal with than the private sector. If we collectively decided that trains in Denmark should be free for passengers, then that would happen. You can't do that in a private business, though security obviously does factor into it.
This is the general story really. Microsoft's copilot studio is relatively new, and it's probably been flying under the radar in a lot of tech circles because it's basically what power automate always wished it could be. Having used it to build a HR flow, where an AI model will receive the applications, read them, auto-reply to irrelevant ones, create a teams site with files and the relevant people for the relevant applications, and invite the applicant to their first appointment. Well... I gotta say that I'm not sure what we have that's an alternative to that. It took me a couple of hours to build it, and it frankly works better than I thought it would. Granted, I did know the tool because I had previously done a PoC where I build a teams agent which "took over" my teams interactions. Everyone noticed because it spelled correctly and wasn't capable of posting Warhammer 40k ORK meme's in any form of quality, but it was frightenly easy. What Microsoft sells in this area is again the governance of it all. You can do these things because of how EntraID lets you connect services seamlessly with a few clicks. While behind the scenes all of those clicks are only available to you because your IT department control them... Again... without hundreds of manhours.
I'm sure we'll eventually get there, but it'll likely come down to change management. Because even if you're willing to retrain your IT operations crew, it's not likely that they will want to leave the Microsoft world where they are well paid and job-secure. Well, maybe I'm in a cheese bell, but I've never met an Azure/Microsoft IT person who would want to work with something else, and having been forced to work a little bit with it behind the scenes, I sort of get it... well not really.
Which boils down to why Microsoft has always been good with enterprise customers. The decision makers in your organisation will listen to everything, but their own IT departments will often sort of automatically recommend Microsoft products and at the end of the day, it'll all boil down to risk. Which is what Microsoft really sells... risk-mitigation. Sure their licenses are expensive, but is it really more expensive than losing your entire IT staff? (this isn't an actual question I'm asking, it's what goes through the considerations.)
This probably reflects my own prejudices, but it always struck me that MS based IT people wouldn’t work with anything else, basically because they couldn’t.
That stack optimises for not really having to understand what you’re doing, but also avoiding any major foot guns (and having the general arse covering that buying IBM used to provide, but which MS now does). The price you pay is that everything is horrible to work with. But if the alternative is not really being able to get anything done at all then so be it?
The Windows ecosystem does a lot of things that, to me, as a Linux/MacOS user, seem like a weird bunch of crazy decisions that are different just because.
Whether that's true or not, it does mean that a lot of people who came up on Windows IT don't have a mental framework for how to run or manage Linux systems. Likewise, when I'm trying to diagnose something on Windows it just seems like the entire thing is a disaster; where are event logs? In the event viewer! How do I filter them? It's a mess! Can I search them? Kind of! Do they have information to help me diagnose the problem? Almost never!
On Linux, I know all the tools I need to solve all the problems that come up; on Windows, I have only minimal concept of how things work, and very little way to diagnose or debug them when they go wrong, which is often.
For example, when my Windows gaming machine comes out of hibernation my ethernet controller insists that there's no connection. I can't convince it otherwise except by disabling the device and re-enabling it. I can't figure out where I might find information that tells me why this is happening, so I just wrote a powershell script to turn it off and then on again. I bet some Windows IT dork could figure it out in 30 seconds, but I'm a Linux IT dork and I have no clue.
> For example, when my Windows gaming machine comes out of hibernation my ethernet controller insists that there's no connection. I can't convince it otherwise except by disabling the device and re-enabling it. I can't figure out where I might find information that tells me why this is happening, so I just wrote a powershell script to turn it off and then on again. I bet some Windows IT dork could figure it out in 30 seconds
Windows and Linux dork here (heh). It has to do with how various computer manufacturers implemented the Sleep/Standby State (S3/S4), how they've resisted implementing a common standard at the hardware level, and how Microsoft eventually gave up arguing and patched around it with their own Modern Standby system in the S0 state.
Tbh, though, the only computer I've ever seen Hibernate work well on are Macs. Every x86 computer usually has some sort of issue with it, except for maybe business laptop models (eg HP's Elitebook line).
All that law says is that the applicant 'shall have the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken.'
And even then, only if a job application rejection 'produces legal effects or similarly significantly affects that person in a way that they consider to have an adverse impact on their health, safety or fundamental rights'.
So as long as the company is recording the decisions taken and the reasons for those decisions, and providing those to candidates on request, they're in the clear.
If they're using a LLM to make those decisions, then they're fundamentally unable to provide the reasons for those decisions, because of how LLMs work.
So that's what's keeping Microsoft from just running WINE on an MS-flavored Linux or perhaps a clean slate kernel as their next OS. I've been wondering for a while, this is by far the best explanation.
The Windows Kernel (and arguably the Windows APIs) are the only good part of Windows; they should dump everything else and run Linux above it; wait they did do that and then changed it to a boring VM.
Yeah but Windows is a more stable api to develop against than Linux (at least when it comes to stuff that games need to do) - it doesn't feel "pure", but pragmatically it's much better as a game developer to just make sure the Windows version works with proton than it is to develop a native Linux version that's liable to break the second you stop maintaining it.
Yes, they are easy to port a lot of the time. Especially now because you can use DXVK to translate DirectX calls into Vulkan, so you don't need to write a Vulkan renderer. Input is sometimes a trickier one to deal with but a lot of the time games are using cross-platform libraries for that already!
Despite all this the Unity engine has spotty Linux support. Some games run better under Wine vs. Unity's native Linux builds. It's Vulkan renderer has had a memory leak for a while now. Input has randomly decided to double keypresses on some distros.
The hard part of Linux ports isn't the first 90% (Using the Linux APIs). It's the second 90%.
Platform bugs, build issues, distro differences, implicitly relying on behavior of Windows. It's not just "use Linux API", there's a lot of effort to ship properly. Lots of effort for a tiny user base. There's more users now, but proton is probably a better target than native Linux for games.
It’s not really about OS differences - as the GP said, games don’t typically use a lot of OS features.
What they do tend to really put a strain on is GPU drivers. Many games and engines have workarounds and optimizations for specific vendors, and even driver versions.
If the GPU driver on Linux differs in behavior from the Windows version (and it is very, very difficult to port a driver in a way that doesn’t), those workarounds can become sources of bugs.
Meanwhile I had to pirate Dark Souls 1 because Microsoft's own DRM prevented the legitimately purchased game from saving on Windows, and download official no-cd patches for two other games because their DRM stopped working.
For games, part of that mere „output” is 3d graphics, so replicating the internals of Direct 3D exactly right and getting the Linux GPU drivers to cooperate. That’s a hardcore task.
You're onto something but that's not entirely true for all games. There's plenty of vintage games, made before DirectX standardized everything into the late 90s, that don't work well under wine because back in their day, they would try to bypass windows by "hacking" their way to the hardware via unsupported APIs and hooks, to squeeze every bit of performance from the hardware, and also because every hardware vendor back then from graphics to sound shipped their own APIs.
90s Windows ran inside of DOS, and you can run e.g. Windows 98 games (through Windows itself) in DOSBox. Look up exowin9x where they're trying to compile all of the necessary configs for one-click launchers.
I tried running the elder scrolls Redguard, on wine, which launches windows version of dosbox with glide support. Redguard is a weird beast which is installed only with windows installer, but the actual game runs in dos mode
Everything works but the frame rate isn't great
If anyone knows a good Redguard setup for Linux please mail me, you can guess my mail easily. Now I just run the gog version
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.
> 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.
Also a big part of the marketing for the SteamMachine/SteamDeck/SteamFrame is that it has a desktop mode and can be used like a pc, so i think they also have an interest in that
i didn’t buy a steam deck since so i can run Microsoft Office. i like that there’s freedom to open up desktop mode to tinker / install 3rd party software, but not to use it as a business machine.
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.
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.
> 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.
Yep. that's the route I tried before, no good, maybe it's just that the documentation is past it's sell by date, maybe it's lack of community use.. I'm just not seeing it. Even the article itself describes how to make an exe file... that will then work in Linux? Or is it simply a program that's easier to run on Wine? Loads of text with unclear details throughout it.
Wine devs do not want to work with people who have looked at ReactOS[0] (see at the end) so any collaboration is one-way (or by ignoring the guidelines) and the likelihood of the two projects merging is zero.
Surprised no one responded to the 7th comment in that linked email thread, the author brought up a good point about making progress without using any disassembled windows binaries.
Very different projects so I would not encourage a merge but sharing a code base? I can totally see that being a boon for both and other Windows emulation projects.
Way back in the 90s when I used OS/2 and running Windows applications required running a fully copy of Windows inside OS/2,¹ I had dreamed of writing something akin to Wine for OS/2, but I lacked the knowledge to do it back then (and still do). I’ve never used it since I never use Linux in a context that it would make sense (for me, as is the case for most Linux users I suspect, Linux is strictly a headless server OS). Apparently Wine is also available for the Mac, but these days I don’t know of a single Windows app² that I would want to run.
⸻
1. A frequent debate about the time was whether this was a wise thing to do as it reduced the motivation for developers to create OS/2-native versions of applications. The slow death of OS/2 can be interpreted as both support for those who felt that Windows-under-OS/2 was a bad idea and those who felt that OS/2 was doomed from the start in the face of the Windows monopoly.
2. Largely because I’m not a gamer—when I’ve looked at what it takes, both in terms of hardware and in learning how to do stuff in games, I’ve decided that I’m happy staying that way.
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.
I’ve only ever used Outlook when forced to by an employer and I find it a dreadful application to use. I would guess that most people prefer something else. I would imagine that most people tend to stick with the default email app on their computer (no idea what that is on Windows as I’ve managed to avoid having to use Windows for 7 years now).
The default mail app on Windows is now called Outlook for Windows, no relation to the Outlook in Office (sorry, Microsoft 365 Copilot), and it's a significantly worse barely functional webview. It also replaced the entire Calendar app, which was decent.
They've really shifted how Outlook works... as well as how the backend is more tuned to the way M365 mail works far more than how it used to work with Exchange, or independently. It's been a slow downslide imo since around 2007 or so.
I know the why, but it's really worse as an experience for most people than the older integrations... but the use of horizontally scalable backends makes for a saner platform at the expense of better UX.
Yes the do have an one time purchase option. You get 5 years of updates but no new features. I have it on my home computers. But new features are not a big deal since the differences are not big anymore (just like mobile phones.)
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.
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.
This extends past linux. Open source projects get used broadly regardless of runtime environment. Steam is just one open nerve ending where this could be used for good and they have the power to do so (and from what we've seen, steam seems to be a low friction company, less corpo red tape - would you trust say Ubisoft with handling this or steam?). If a game gets deployed to windows, it doesn't matter, as each game/application probably use five or ten or more open source projects regardless of where they run. It can help open source devs keep pacing with steam and game developer needs. Remember a ton of these project have upstream effects outside of gaming - its just the most obvious open nerve we can use to help open source.
You can only show the checkbox on Linux. You can add OS detection to the checkbox and have it say "support our $OS dependencies" and put that into different pots of money. You can make the checkbox say "support our Linux dependencies" and then rely on Windows people not selecting it.
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.
Oh absolutely, I would welcome some way of sponsoring such projects in general. I just meant to highlight that for this particular feature and project, there is already a form of sponsorship happening.
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.)
Ironically, SQL Server AFAIK in order to run on Linux uses what basically amounts to a Microsoft reimplementation of Wine. Which always makes me wonder if they'll ever get rid of Windows altogether someday in favour of using Linux + a Win32 shim. I think there are still somewhat strong incentives nowadays to keep NT around, but I wouldn't be that surprised it this happened sometime down the line.
AFAIK it's more like a reimplementation of NT APIs in userspace - aka basically Wine with extra steps, or Linux UM. There was a slide deck going around about Project Drawbridge, here: https://threedots.ovh/slides/Drawbridge.pdf
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.
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.
More or less Wine + some experimental patches not yet I twgrated in mainstream wine + a buch of DirectX translation libraries + close steam integration.
There's also Proton-GE [1], which is even more experimental and adds some bleeding edge fixes and features.
I've heard it's pretty good for fixing video playback/rendering (e.g. cutscene) issues if both the stable and the experimental branch of Proton can't make it work.
A lot of what Proton-GE brings from my understanding is a larger support for Media Foundation, which can't be added to Proton itself because of license issues (Proton is from a commercial company, where Proton-GE is from an individual).
So aside from the stuff that has been implemented differently, running Proton instead of Proton GE is like trying to game on Windows N editions.
There is also UMU Launcher[0] which is basically all that without the Steam integration/dependencies so you can run games from GOG and other stores (it is a command-line tool but launchers like Heroic can use it behind the scenes). I used to install dxvk, etc manually but in recent months i switched to it as it tends to work much more seamlessly for games (i did disable its autoupdates though).
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.
The common gaming-focused Wine/Proton builds can also use esync (eventfd-based synchronization). IIRC, it doesn't need a patched kernel.
The point being that these massive speed gains will probably not be seen by most people as you suggest, because most Linux gamers already have access to either esync or fsync.
Maybe you are right about esync but anyway I would also gather a lot of people don’t have that either. At least personally I don’t bother with custom proton builds or whatever so if Valve didn’t enable that on their build then I don’t have it.
> if Valve didn’t enable that on their build then I don’t have it.
The Proton build is Valve's build. It supports both fsync and esync, the latter of which does not require a kernel patch. If you're gaming on Linux with Steam, you're probably already using it.
I would assume most of them? I'd be surprised if distros like Debian, Ubuntu, Fedora, etc. would ship non-mainline kernel features like that.
Sure, gaming-focused distros, or distros like Arch or Gentoo might (optionally or otherwise), but mainstream? Probably not.
Of course, esync doesn't require kernel patches, so I imagine that was more broadly out there. But it sounds like fsync got you performance pretty close to what ntsync can do, but esync was quite a bit behind both? With vanilla being quite a bit behind esync?
(Also, jeez, fsync, what a terrible name. fsync is a syscall that has to do with filesystem data. So confusing.)
Last I checked, every distro of note had its own patchset that included stuff outside the vanilla kernel tree. Did that change? I admit I haven't looked at any of that in... oh, 15 years or so.
If you read more carefully it says fsync needs some enhancements to the futex API, called futex2. The original patch that fsync needed called the syscall futex_wait_multiple. Eventually futex2 made it into the mainline kernel, but the syscall is called futex_waitv. Not sure if the wine fsync implementation was updated to support the mainline kernel futex2 implementation.
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 really valuable CRUD monkeys are already domain experts as well. The threatened ones are junior developers whose output is barely better than AI slop.
> The really valuable CRUD monkeys are already domain experts as well
Sure but that’s a minority I’d argue. There wouldn’t be such a volume of shitty business software otherwise.
I will be interested to see if there are any economic effects of ending one of the last well paid, low barrier to entry careers in which some level of meritocracy was permitted.
You can tell from my comment that I'm not AI. I've had a lifelong habit of using commas instead of dashes in situations where the dashes would have been more appropriate. AI would always go for the dash.
The grass is always greener on the other side - many low-level programmers feel like an imposter when it comes to high-level systems such as CRUD apps.
Can confirm, my buddy who is someone I respect immensely, is an embedded programmer.
He will talk about OS events, or any low level concept and it makes me feel like I don’t know anything, but he acts like I’m a genius if I talk about JavaScript Runtimes, browser engines, anything frontend.
It’s cool he teaches me new things, I teach him some
Some people are exceptional at solving difficult but hard to explain problems while other are great solving direct business problems. No need to feel ashamed for both it’s just different work
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.
I work on OS/embedded and my wife in server backend. I definitely feel like a simpleton when trying to understand all of the high level stuff she works on. It doesn't invalidate my own expertise. There is nothing wrong with acknowledging someone has skills that you don't have and likely would take a long time to pick up.
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.
Trivial under plan9/9front. Under Win32/POSIX, run way.
On bit shifts, pick any Forth programmer and shaders will be almost like a toy for them. They are used to implement double numbers (and maybe floats) themselves by hand by just reusing the only integer numbers they have and writting custom commands to output these pairs of integer as double numbers. They can probably implement multithreading processing by hand in Forth and also know the IEEE standards for floats better than C programmers over 20 years.
I know literal kernel developers who can handle drivers and race conditions any day of the week who can't wrap their mind around Outlook, let alone GUI updates.
Myself. Forth it's easy, 9front C it's manageable but POSIX it's hell and managing both Unix descendants are a piece of cake.
GUI interfaces for the enterprise came from Dante's hell themselves. I hate them, they are like the Madhouse from that Asterix movie making satire of the European bureucracy of the day. The often are oddly designed and they are not documented at all, you must guess the meaning by chance of with a senior tutoring you.
The same with anything corporate from Microsoft with AD roles/group policies and the like. Or anything coming from IBM.
lol you guys are being too nice. Building CRUD apps is just implementing business logic by gluing APIs together, there is nothing to understand except the business domain, which is only done through exposure, because business logic is random. And then the APIs which are all essentially a kludge because of the shifting business logic.
Understanding low level code puts you on entirely different level because you can reason about a problem using logic and how systems operate.
No disrespect to any crud devs here but from my personal experience they just know a particular implementation of their domain and rarely even consider how the code base even operates as a whole
> lol you guys are being too nice. Building CRUD apps is just implementing business logic by gluing APIs together, there is nothing to understand except the business domain, which is only done through exposure, because business logic is random.
It isn't "random", a as business process develop over time to various business/customer/regulatory needs. The business process evolves over time typically.
When you take a business process, you are often formalising it. The fact that you have no appreciation of this, tells me you don't really understand what you are talking about.
> Understanding low level code puts you on entirely different level because you can reason about a problem using logic and how systems operate.
You have to do this in high level languages as well. It isn't something that only low level devs do. In fact to be able to write any good code you need to understand the problem domain.
> No disrespect to any crud devs here but from my personal experience they just know a particular implementation of their domain and rarely even consider how the code base even operates as a whole
You are literally disrespecting them by saying this. It is also false, what you are describing is developers having deal with incomplete/poor specifications and poor documentation. BTW this is rampant through the industry. I wanted to do some stuff yesterday with Docker and Go, the documentation is non-existant.
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.
no database for this project - the data model has a simple text representation so it gets serialized out to a folder/file layout on disk that goes into version control. single self-contained binary: contains the web/websockets server, backend logic, parser/serialization. there is a separate component in python that sits behind an internal network connection to handle an execution sandbox.
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.
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.
You’re still an engineer. Knowing the right places to click in an esoteric app is like knowing where to hit the boiler with a hammer to get it working again.
I am glad that a portion of the thousands of dollars I've given to Valve Corporation over the years has been gone to improve Wine for everybody. I wonder how many developers and contractors on the project are paid by Valve.
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.
Wine might be oddly self-defeating. Broad game support on Linux increases the viability of Linux as a desktop, which increases market share, which may result in developers creating Linux ports as a 1st class concern, which don't need Wine to run.
I've experienced multiple instances where (so I heard; I don't use Windows) a Windows Update completely broke a game on Windows for everyone, but Wine/Proton kept running it just fine. So we're already there in some sense.
What I wonder about is if MS wants to keep people on windows, what methods they can use to do that. For simple desktop stuff I don't think they have many options to lock in other developers (and their audiences) to windows unless they want do so themselves (putting aside web based or not PC-desktop).
Bleeding edge gaming and multiplayer anti-cheat is one area where I think having a big company owning the OS probably helps them stay ahead, as that structure probably lets them work with hardware designers to get the capabilities in use (i.e. in new versions of DirectX) and available to software developers first. There's generally a lag in adoption for new features within Vulkan and then usage downstream in wine/proton to get compatibility parity with windows, then the games themselves being able to run feature/performance parity. It'd be interesting to see what cooperation would be needed to have the linux gaming stack equal at the point new features are released, and with the least amount of manual hacks or command line tweaking required for the users. As discussed a few weeks back, tough anti-cheat for linux seems like a paradox with the current methods.
> What I wonder about is if MS wants to keep people on windows, what methods they can use to do that
Microsoft doesn't give a fuck about private customers any more. They don't have money.
What has money though is enterprise/government sales, and MS got these customers tightly locked in. Compliance audits and tooling for insurances or legal stuff (SOX, GDPR, ...) are built against a full Microsoft stack of MS Server, Active Directory, Azure, Teams, Office 365 and Windows desktops.
You might be able to get away with replacing AD and GPO with Samba servers but even that is already a pain when the auditors come knocking. Everything else? There is no single FOSS based "standard offering" (i.e. a combination of everything needed to run an on-prem enterprise site, Office replacement, remote collaboration tooling), so every audit for such setups must be custom made and involves a lot of extra work.
A second leg is industrial control machines, medical devices and the likes. That's all stuff built by third party vendors and integrators. They need to continue on Windows because switching to an alternative OS would require redoing everything from scratch on the software and certification side. These customers buy the LTSC IoT stuff.
And that is why you see Microsoft pushing enshittification so hard on private customers... extract the last few cents you can from them. But the real money comes from the large customers.
For a while it seemed like Microsoft wasn't taking Windows seriously as a product. And the easiest way to cut costs on that is to use a solution someone else is building and maintaining. They did retire Internet Explorer in favor of a Chromium browser, so it wouldn't be unprecedented.
It certainly runs 16-bit Windows games better than Windows 11, which can't run them at all. Not that there are a ton of those, but it's still pretty neat that they work.
Time to dust off my cd copy of Stars! (From the disk backup, the cd had terminal illnesses and has died). The only win16 game I've ever seen distributed on CDROM. Wine already ran it ok (iirc there were some issues but nothing gamebraking), but now it can do so without i386 libs.
The thing that you're missing is that Microsoft used to ship that emulator with Windows. Then they stopped doing that.
AFAICT, Wine can run WIN16 programs. I don't know if it can run DOS programs. There's a WineHQ wiki page that says it can load DOS programs, but various internet fora seem to believe that Wine's DOS support is pretty broken. I've never tried it, and have no DOS programs handy, so I can't verify those claims.
"DOS support" is tricky inasmuch as a lot software from that era - especially larger and more complex packages - interacted with hardware directly. In a sense, they weren't really DOS applications so much as they were bare-metal PC applications which were booted from DOS. It'd be difficult for WINE to support those, and other projects like DOSbox / 86box / etc do a better job of it.
MS got such a black eye for that that they're developing a build of windows specifically for handhelds, optimized, without the bloat and power hungry extras. Would be nice if it ran on laptops
Anything Direct Draw related will be mapped into OpenGL under Unix giving you decent speeds. On Windows it will be a crawling slideshow because from Windows 8 and up it will use a really dog slow software mode with no acceleration at all, worse than plain VESA. Yes, you can reuse WineD3D DLL's on Windows and run these game in a fast way, but not by default, it's a Win32 port of some Wine libraries.
I had to use WineD3D's ddraw.dll among another one to run these touch based arcade machine games with card games, Trivial Pursuit, hangman and the like. If not the game made for w98/2k would really lag even under an i3.
The same with some multimedia CD's from its day. Scummvm it's partially implementing Macromedia Director support but the mentioned game had a custom engine. The Scummvm devs would RE in few weeks (it's a simple 2D game bundle, nothing difficult, with virtually no animations, almost everything it's still images) but no one began yet.
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
> What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.
Is this correct? I think you perhaps have it backward? If I compile something against the glibc on my system (Debian testing), it may fail to run on older Debian releases that have older glibc versions. But I don't see why an app built against glibc 2.12 wouldn't run on Debian testing. glibc actually does a good job of using symbol versioning, and IIRC they haven't removed any public functions, so I don't see why this wouldn't work.
More at issue would be the availability of other dependencies. If that old binary compiled against glibc 2.12 was also linked with, say, OpenSSL 0.9.7, I'd have to go out and build a copy of that myself, as Debian no longer provides it, and OpenSSL 3.x is not ABI-compatible.
> glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed.
If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux. And I wouldn't blame them.
I don't know what the official policy is, but glibc uses versioned symbols and certainly provides enough ABI backward-compatibility that the Python package ecosystem is able to define a "manylinux" target for prebuilt binaries (against an older version of glibc, natch) that continues to work even as glibc is updated.
Sorry I am not sure if 2.12 is a a recent release or older, I made up this number up
If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work
>If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux.
Not really a show stopper, vendors just do what vendors do and bundle all their dependencies in. Similar to windows when you use anything outside of the win32 API.
The only problem with this approach is that glibc cannot have multiple versions running at once. We have “fixed” this with process namespaces and hence containers/flatpak where you can bundle everything including your own glibc.
Naturally the downside is that each app bundles their own libraries.
The only problem with this approach is that glibc cannot have multiple versions running at once
that's not correct. libraries have versions for a reason. the only thing preventing the installation of multiple glibc versions is the package manager or the package versioning.
this makes building against an older version of glibc non-trivial, because there isn't a ready made package that you can just install. the workarounds take effort:
So in practice you can only have 1 linker, 1 glibc (unless you do chroot or containers and at that point just build your stuff in Ubuntu 12.04 or whatever environment)
it's not that simple. you want to be able to use a modern toolchain (compilers that support the latest standards) but build a binary that runs on older systems.
the only way to achieve that is to get the older libraries installed on a newer system, or you could try backporting the new toolchain to the older system. but that's a lot harder.
It may be hard-ish, sometimes. Sometimes it's a breeze. And sometimes you can just use host's toolchain with container's sysroot and proceed as if you were cross-compiling. Most of the time it's not a big deal.
MUSL is a better libc for companies making proprietary binaries. They can either statically link it, or provide a .so with the musl version they want their programs to use & dynamically link that.
This a toolchain issue rather than OS issue. This wounldn't have been a problem if gcc/clang just took a --stdlib-version option and built the executables linking to that version of glibc or equivalent.
I am sorry, I did not mean to imply anyone else is doing something poorly. I believe glibc's (and the rest of the ecosystem of libraries that are probably more limiting) policies and principled stance are quite correct and overall "good for humanity". But as you mentioned, they are inconvenient for a gamer that just wants to run an executable from 10 years ago (for which the source was lost when the game studio was bought).
No other operating system works like this. Supporting older versions of an OS or runtime with a compiler toolchain a standard expectation of developers.
Plenty of operating systems work like this. Just not highly commercial ones because proprietary software is the norm on those.
From a bit of research it looks like FreeBSD for example only provides a stable ABI within minor versions and I imagine if you build something for FreeBSD 14 it won’t work on 13.
Stable ABI literally only benefits software where the user doesn’t have the source. Any operating system which assumes you have the source will not prioritize it.
(Edit: actually thinking harder MacOS/iOS is actually much worse on binary compatibility, as for example Intel binaries will stop working entirely due to M-cpu transition - Apple just hits developers with a stick to rebuild their apps)
> Stable ABI literally only benefits software where the user doesn’t have the source
Stable ABI benefits everyone. If I need to recompile a hundred packages with every OS update instead of doing real work then there's something seriously wrong with my OS.
Yes, and this is a great reason why FreeBSD isn't a popular gaming platform, or for proprietary software in general. I'm not saying this is a bad thing, but... that's why.
> Stable ABI literally only benefits software where the user doesn’t have the source.
It also benefits people who don't want to have to do busywork every time the OS updates.
FreeBSD isn't too bad, you can build/install compat packages back to FreeBSD 4.x, and I'd expect things to largely work. At previous jobs we would mostly build our software for the oldest FreeBSD version we ran and distribute it to hosts running newer FreeBSD releases and outside some exceptional cases, it would work. But you'd have to either only use base libraries, or be careful about distribution of the libraries you depend on. You can't really use anything from ports, unless you do the same build on oldest and distribute plan.
At Yahoo, we'd build on 4.3-4.8, and run on 4.x - 8.x. At WhatsApp, I think I remember mostly building on 8.x and 9.x, for 8.x - 11.x. The only thing that I remember causing major problems was extending the bitmask for CPU pinning; there were a couple updates where old software + old kernel CPU pinning would work, and old software + new kernel CPU pinning failed; eventually upstream made that better as long as you don't run old software on a system with more cores than fit in the bitmask. I'm sure there were a few other issues, but I don't remember them ...
Apple said they will keep Rosetta 2 for select usecases, such as gaming. They do have a user base that uses Steam and bought mac games - without rosetta that would mean the users could no longer play their game. And no one ports 5-10year old games.
Can one run a windows version of a game well over on say, a MBP?
I ask because my current laptop is getting long in the tooth, and if I were just buying it for productivity stuff, the current MBPs are beasts, but last time I checked years ago, gaming on os x was in a sad state, even compared to linux.
macOS doesn't require developers to rebuild apps with each major OS release, as long as they link with system libraries and don't try to (for example) directly make syscalls.
Apple may require rebuilds at some point for their Mac Store (or whatever they call it), but it's not required from a technical perspective.
The one exception here is CPU architecture changes, and even then, Apple has provided seamless emulation/translation layers that they keep around for quite a few years before dropping support.
I actually think it'll be the opposite. Even for games that have native ports I pretty much always run the Windows version with Proton, since that just tends to be more stable. People develop against the Windows API because it's familiar and somewhat unchanging, and that's fine since Proton does such a good job running it.
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.
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.
Maybe, but the incentive runs the other way. If Windows compatibility gets good enough, game devs have even less reason to pay for Linux QA and support, and Valve plus GPU vendors can live with that because the cost gets pushed onto Wine and Proton chasing Windows' quirks forever with hacks and syscall glue.
Not really. I actually tried building an "old" game (read: not updated since 2014 or so) on Linux when I used it. It didn't work because autotools changed, some weird errors with make, and the library APIs have changed too.
In the end I gave up and just used proton on the windows .exe. Unbelievable. :(
I should clarify my original comment about stability only applies to glibc itself. Once we go out of glibc there will be varying degrees of API/ABI stability simply because at that point it’s just different groups of people doing the work
In some cases such libraries are also cross-platform so the same issues would be found on Windows (eg: try to build application which depends on openssl3 with openssl4 and it will not work on either Linux or windows)
For future reference if you ever need to do that again, it would be way easier to spin up a container with the build environment the software expects. Track down the last release date of the software and do podman run —-rm -it ubuntu:$from_that_time and just build the software as usual.
You can typically link the dependencies statically during build time to create system independent binaries. So the binary produced inside the container would work on your host as well.
Even if all games were FOSS, without - at least - a stable API, most games will remain a hassle to run. DOOM doesn't deal as much with this due to the high amount of volunteers, but relying on community support for all games is just outsourcing labor to some unlucky fellows. At best, it's yet another pain for Linux users. At worse, it's the death of unpopular games. Either case, a hurdle for Linux adoption.
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
I am playing both modern and old games on Linux. Games outside a super narrow enthusiast realm are always closed-source (even indie ones) and it's going to stay like that in the foreseeable future, that's just a fact of life and gamedev incentives and specifics.
Wine has constant regressions. What works fine today will completely fail next year. Which is why steam lets you pick which proton version you want to use.
Which means that a .exe without the exact version of wine won't run.
Plus of course there's the whole vulkan stuff. Older cards aren't well supported but it will rather crash than just run openGL normally where it would work fine.
In practice, Wine is constantly improving. It's in active development and not that stable, but regressions are mostly local. Treat its releases like bleeding edge.
>What works fine today will completely fail next year.
Usually not on the timescale of a year. I have many new games that worked a year ago and none of these stopped working now. The worst breakage I had recently was some physics glitches in an old RPG (released in 2001) on Wine 11.0, and it was fixed in the next release.
Those issues seem othorgonal to stable ABI issue from OP, specially the OpenGL one (that is more like a hardware incompatibility issue). When apps fail to run due to Wine updates, they are considered bugs to be fixed. On the native side, apps may break becuase:
1) required library is unavailable, normally because it is too old and unsupported;
2) required library's path is different in distro A from B.
None of these are considered bugs and, as such, are rarely addressed. I believe Steam Linux Runtime is an attempt at fixing this,but I'm not sure about its effectiveness.
Also, you are exaggerating on the "exact Wine version". It helps to know which versions don't have a regression by knowing which specific version an app used to run on.
It seems more likely to me that the Windows API will become the de-facto Linux gaming SDK, and the idea of porting a game to Linux will become meaningless.
Possibly but does it realistically matter? I don't care why my games run on linux I just care that they do. I encountered a few cases where the native version was inferior to the wine version (Cronos is one example). With wine improving there is very little downside to just using it.
Could there ever be a killer app for Linux? One that would cause a not-insignificant number of people to decide that Linux was worth switching to, even if there was some pain of moving away from Windows?
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 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
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.
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 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 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 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.
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.
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.
People such as Figura and Bertazi have been attempting to do what you propose for most of a decade now[1]. They've ended up with this, after two previous implementations running in Wine for many years. Thier reasons are explained in their documentation[2]. Perhaps you know better. We all look forward to your work.
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
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).
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?
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).
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.
Linux native semaphores are enough. Linux has been able to be very performant without it. That feature seems like way too over engineered for little gains.
Reading the link provided by https://news.ycombinator.com/item?id=47511778, I believe "atomically acquire multiple objects". The link states they try to emulate it by performing a poll then a read, but the gap between those results in a race, which is a terrible thing to have in a synchronisation primitive.
There was also something about needing to back out if any of the reads fails to acquire, which also sounds nasty.
Ah, interesting, so wfm does both the wait and the acquire!
When using eventfd it is indeed annoying having to both poll and later read to disarm the object (there are epoll tricks that can be used but are not generalizable).
The signal+wait is also a primitive that it is hard to implement atomically on posix.
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 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...
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.
That’s a wild exaggeration. Yes they underperform relative to the Windows drivers but my experience is far from “cutting framerates in half” nor “borderline impractical”. I’ve had the last four generations of Nvidia card (currently on 5070Ti) on Linux and played demanding games just fine.
This is not true at all. I game on Linux (Arch, btw) on my 3090 and every game not using some kind of kernel-level anticheat just works. I have never made formal comparisons, but my experience is that I can't notice a difference in performance relative to Windows most of the time. One exception was Helldivers 2, but the performance gap has more or less closed recently with recent Proton versions.
The only problem with Nvidia in the last... 5 years was their wayland support and their worse than expected performance for DX12 games. Both of which were being actively worked on, where wayland support has been improving since 2 years ago and DX12 performance needs patches on all the stack, the driver is there, mesa and vkd3d patch are pending.
> 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.
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.
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.
> 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.
Now if only Steam would add a checkbox on their checkout page to add 10% donation/tip that goes directly to their upstream opensource dependencies (like the Wine team), that would be amazing! I would add extra money on every purchase to support these people!
Buy a steam deck. It sends a strong signal to Valve to continue supporting Wine and you get a Steam Deck
I'm in Africa, when I go to the steam deck page, it says it is not available in my country. Not interested in buying from a third party importer. So until then..
I wanted to buy the entire new lineup (Machine, VR, and controller), but alas, AI RAM shortage. I hope it can get released soon.
Unfortunately Steam decks have been out of stock for a while. The AI slop Apocalypse ruined the consumer computing market with chip shortages.
it's was out of stock as soon as they came out and in a lot of countries outside of the US it wasn't available.
https://www.winehq.org/donate
Requires PayPal or credit card. The suggestion was to pay with your Steam Wallet or whatever payment method already used when you buy a Proton-based game on Steam.
> Donate to the Wine Development Fund by cash, cheque, or international money order in US dollars.
IMHO this supports the original point that payment via Steam would be an upgrade:
Sending cash to a postal address isn't low-effort nor low-risk.
Payment by cheque is something I have never done, nor would I know how to do it. I'd have to ask at my bank -- not low effort. I don't know if I'm an outlier here but I have never heard from any of my peers who ever did such a thing.
The same or even worse is true for international money orders. The whole concept of making a money transfer to a postal address is something I have never heard of. Where's the IBAN?
The Wine team is right to put even PayPal before all of these.
Can you have a Steam Wallet without having a credit card?
Yes, I do. It just means that you have to manually "recharge" your Steam wallet when it runs low. That's some effort, but it limits the possible damage if something goes wrong.
How do you "recharge" you Steam Wallet? Gift cards, I assume?
Yep, depending on where you live you can probably find them wherever you find other major brand gift cards.
The best low overhead way to support them for Americans is to set up bill pay with their bank and auto send checks to their mailbox
for 99% of people it will also probably be paypal or credit card
i pay for crossover license (wine on mac), if i understand correctly, they spend this money on development wine core as well.
You always give 30% to Valve and their interests so far are aligned. Everything that's possible within the Steam ecosystem is available outside of it. Maybe things will change in the future, but I doubt we could be getting a better deal.
Value does pay for development on open source projects already.
https://news.ycombinator.com/item?id=34061110
This is a fantastic idea. I completely endorse it. I hope a Valve employee sees this.
> if only Steam would add a checkbox on their checkout page to add 10% donation/tip that goes directly to their upstream opensource dependencies
Or how about instead of passing the cost off to users, Steam actually supports them from their own profits? After all, they are profiting from free work.
We can't be pushovers about this.
As far as I can tell, Valve makes significant contributions back to Wine via Proton development. Isn't that essentially them supporting their upstream dependencies with their own profits, by using some of those profits to pay people to contribute work to their open source dependencies?
Valve pays over a hundred open source developers to work on the various open source projects that they rely on so heavily, so yeah Valve's 30% of your Steam purchases is already contributing to these open-source projects (like Mesa, the Linux kernel, Wayland, etc.)
https://www.pcgamer.com/valve-is-paying-a-whole-lot-of-devel...
No.
Great idea!
Such donations might even be tax-deductible revenue for Valve, so even the finance bros should love it.
Although I would prefer if Valve simply commits to a fixed percentage of its Steam fee to be donated...
Forwarded donations are not tax-deductible (in the US); That's a lie that's been spread around the internet. If you give a company money with the express purpose of them forwarding it to someone else (the company acts as a "collection agent"), it's not their income or donation.
https://taxpolicycenter.org/taxvox/who-gets-tax-benefit-thos...
Interesting, thanks for the details.
So it would be actually financially _better_ for Valve to donate a portion of their revenue and state "we will donate x% of the price to yy", as THEN it would be tax-deductible for them
It's not better, because being revenue and donated away and tax-deductible all cancels out. It's as if they never saw the money, just like forwarding it.
And even if it was, all "tax deductible" would mean is that they wouldn't have to pay taxes on that money. Which, you know, they don't get to spend. So it's kind of defacto tax deductible in the same sense that my friend's income is "tax deductible" for me, I guess.
A lot of people online have convinced themselves that "tax deductible" means that the government would refund you that dollar amount. That's a "tax credit"... If forwarded donations were a tax credit, then yes, rounding up is giving the company "free" money! But you're not.
I really is impressive. I wish publishers like EA and anti-cheat developers weren't so reluctant to support it. I hope Steam devices and SteamOS gain enough traction to force their hands.
Paying for a game that inserts rootkits into your kernel feels like paying money to get molested. no thanks.
Hate to be the one saying this, but that rootkit is there to prevent you from molesting/cheating other players. So its not an one-sided issue. It is unfortunate that the developers found no other way of fighting cheats, sure.
And by all means, if a game community is so toxic that it has to be policed by extreme measures, it is perhaps indeed better to avoid playing such a game altogether.
agreed. if a condition of attending an event was that I had to wear a chastity belt that prevented guests from raping each other, I'd think twice about attending alltogether.
I don’t care if my shooter game “community” is toxic. I don’t have any interaction with the “community” other than to try and virtually kill its members. I wish my chess app had anti-cheat, there are just some people who will cheat and any game is more fun if they can be prevented from playing.
Idk, kernel anti cheat is a pretty clear sign to me that I should pick a different game to play anyway...
Ironically the only way I would ever consider robust anti-cheet is if the game installed a seperate bootable Linux witch didn't have the encryption keys for my main partition.
you may be on to something here. "you want to play our game, boot it off a usb drive"
Does windows make it easy to tell the installer wants to install kernel anti cheat? It used to pop up the generic binary "This application wants to change files on your computer" which could be installing in the protected "Program Files" or could be modifying anything.
I dont think you can even load the "windows" kernel module in wine. Last time i tried with the capcom rootkit, it didnt work at all.
I read the person I was responding to saying they avoided games with root kits for moral, not technical, reasons. So I assumed they were on Windows, and AFAIK, windows just offers binary "changes" permissions which covers anything from installing in the slightly protected Program Files directory to installing a rootkit. In other words, can they even detect they are about to install a root kit?
Good question and one I am now looking into
Wine doesn't emulate the NT kernel; Just the NT and Win32 userspace APIs. For example, Wine provides a `kernel32.dll` that maps API calls into the appropriate Linux ones. Anything kernel level is operating "below" Wine.
https://www.gamingonlinux.com/2026/03/ea-javelin-anticheat-j...
Because anti cheat on linux is completely useless.
By and large Im happy to not participate in games that use kernel level anti-cheat.
It's reached the level where a game not working is a suprise.
Space Marine 2 was the latest one for me, but Steam is great at refunds if you do it quickly enough.
> and should be for most games that don't use kernel-level anticheat.
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!
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
The hype/performance mismatch was significant in the 2000s for Wine. I’m not sure if there was any actual use case aside from running obscure business software.
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?
I used WINE a lot in the 2000s, mostly for gaming. It was often pretty usable, but you often needed some hacky patches not suitable for inclusion in mainline. I played back then with Cedega and later CrossOver Games, but the games I played the most also had Mac ports so they had working OpenGL renderers.
My first memorable foray into Linux packaging was creating proper Ubuntu packages for builds of WINE that carried compatibility and performance patches for running Warcraft III and World of Warcraft.
Nowadays Proton is the distribution that includes such hacks where necessary, and there are lots of good options for managing per-game WINEPREFIXes including Wine itself. A lot of the UX around it has improved, and DirectX support has gotten really, really good.
But for me at least, WINE was genuinely useful as well as technically impressive even back then.
Also these apps changed, A lot of windows programs were simple executables and I remenber for a moment it was very popular for developers to write portable apps that were just a .exe that you ran,also excel and other programs worked fine, but then microsoft and others started to use msxis or whatever it's called and more complex executable files and it was not longer posible, and microsoft and adobe switched to a subscription based system.
I remember it being surprisingly decent for games back then. Then a lot of games moved to Steam, which made it way harder to run them in Wine. Of course there was later Proton for that, but not on Mac.
Red Box: https://lowendmac.com/1997/red-box-blue-box-yellow-box/
I ran Wine end of 90s to run CS (Half-Life), and I had not only more FPS than Windows. It was more stable as well.
It took some futzing. The crusty PlayOnLinux UI is permanently etched into my brain.
Transgaming! It worked for ons or two games for me, bit it was glorious.
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.
You're saying that Windows' system interfaces aren't stable? In comparison to Linux?
The API underneath the Win32 API, the Windows Native API, is not necessarily stable and therefore not intended for direct consumption by applications.
win32 dates back to 1993. OP doesn't know Windows history. Maintaining backwards compatibility was always a huge priority for Microsoft, even if it couldn't be perfect.
If a program didn't work on a newer version of Windows, there's a good chance it was doing something unsupported.
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.
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.
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.
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.
Yeah, people forget that MS Office, and Excel and Outlook in particular, are the real foundation of Microsoft's vendor lock-in on the desktop.
Outlook is now basically an Electron app, they've deprecated the old desktop Outlook in favor of a port of the web app to desktop, so it's basically just Excel remaining.
Yeah, that's because Microsoft can see the writing on the wall. They don't want Windows to die, but they know the whole OS is at a point where it's probably inevitable that it will.
Developers don't want to use Windows anymore. They all want to run Linux because servers do. Ballmer was right about one thing: It was about the developers.
Microsoft can't compete with Chrome at the K-12 level. A Chromebook is a fraction of the cost at twice the runtime, so nobody is going to learn Windows growing up. There won't be a generation of new ready-trained Microsoft consumers every year.
And the average consumer? Oh, they're running an iPhone and maybe an iPad that's it. If Apple were really smart they'd have released an iPhone screencast dock, but Apple still thinks the iPhone doesn't need multiple user profiles. However, even with Apple's stupid behavior, they're losing their core consumer audience.
Steam is tired of Microsoft, too, so they're pushing for compatibility. Video games are either cross platform, console exclusive, or easy enough to emulate. If nVidia's graphics drivers weren't so proprietary, it wouldn't be nearly as difficult.
The big holdouts are the same people that kept COBOL a live programming language in the 21st century: The business office folks.
Microsoft has missed the boat on smartphones, tablets, budget laptops, smart TVs, video game consoles (which is a little surprising), server-side infrastructure, development, and now AI. Their market prospects right now are Millenials and older that don't want change, people who need exactly Excel or Outlook, and PC video gamers that aren't interested in change. Their best product is VS Code and it's free, their second best product (SQL Server) is pricing people out, and their third best product (.Net) is also free.
At this point I think they're mainly hoping Adobe doesn't jump ship.
> Outlook is now basically an Electron app
And it's horrible.
Electron apps also basically don’t work in Wine. I miss having Evernote on Linux.
Wouldnt it be possible to extract the files you need and sort of "repackage" it for linux?
I have no idea how electron apps look "internally" but it doesnt sound too bad.
Sort of like you can unzip .deb files and use them somewhere else, if what i heard was correct (never tried it myself)
If the Electron app is pure JS with no native extensions it can be doable. However, many Electron apps contain platform-specific js code, since features for stuff like Dock on Mac and Taskbar icons on Windows differ. Electron apps like Notion also contain native extensions - compiled C/C++/Objective-C code that are platform specific. For example in Notion, we use sqlite via better-sqlite3 (potentially replaceable since it’s open source, but will need more work than “just” repackaging js), but we also write our own native support libraries to use OS-specific APIs for microphone recording in meeting notes feature.
I have seen many people porting such apps, like there is aur package for notion, figma
It's cool that arch users give porting Notion a valiant effort. But as I predicted, custom native extensions will be [a problem](https://aur.archlinux.org/packages/notion-app-electron#comme...):
> Could it be possible to make the relatively new AI meeting notes feature to work?
> Right now I get the following error when I click the "start transcribing" button:
Not my area of expertise so I could be wrong but Electron apps just use Chromium underneath (which already works on linux), so in theory it should be easier to get them running on linux than a native Windows app
How is that even possible? I expect you have to go out of your way to make it platform dependent, are you sure?
Electron is basically just a GUI framework. The application itself can be arbitrarily complicated, nothing stops you from building a Java + .NET + C++&COM app that includes three Windows Services that interfaces with the Electron runtime just for UI.
Having worked in non-swe enterprise for two decades I would argue that this is less true today than it was 10 years ago. It used to be that new hires would come with a basic knowledge of windows and office, but that's no longer the case. At the same time, you have things like Smartsheets and so on, which are more popular, at least with our employees, than Excel and everyone seems to hate Outlook these days. I don't think it was ever really the case though. What Microsoft sells to enterprise is governance, and they really don't have any competition in this area.
Being in the European energy sector we're naturally looking into how we can replace every US tech product with an EU/FOSS one. It's actually relatively easy to buy the 365 experience through consultants which will setup a NextCloud, Libre/Only Office, Proton and a teams replacement I can't for the life of me remember the name of. Beneath it there is a mix of Identity Management systems, often based around Keycloak, at least for now. It works, from what we've seen in Germany (specificlaly with their military) it's also possible to roll it out relatively quickly. It's all the "other" stuff that gets murky. There isn't a real alternative to AD/Entra, yet, from a governance perspective. There are great tech solutions which does the same thing, but they require a lot of IT man hours. Something the public sector is always going to be more willing to deal with than the private sector. If we collectively decided that trains in Denmark should be free for passengers, then that would happen. You can't do that in a private business, though security obviously does factor into it.
This is the general story really. Microsoft's copilot studio is relatively new, and it's probably been flying under the radar in a lot of tech circles because it's basically what power automate always wished it could be. Having used it to build a HR flow, where an AI model will receive the applications, read them, auto-reply to irrelevant ones, create a teams site with files and the relevant people for the relevant applications, and invite the applicant to their first appointment. Well... I gotta say that I'm not sure what we have that's an alternative to that. It took me a couple of hours to build it, and it frankly works better than I thought it would. Granted, I did know the tool because I had previously done a PoC where I build a teams agent which "took over" my teams interactions. Everyone noticed because it spelled correctly and wasn't capable of posting Warhammer 40k ORK meme's in any form of quality, but it was frightenly easy. What Microsoft sells in this area is again the governance of it all. You can do these things because of how EntraID lets you connect services seamlessly with a few clicks. While behind the scenes all of those clicks are only available to you because your IT department control them... Again... without hundreds of manhours.
I'm sure we'll eventually get there, but it'll likely come down to change management. Because even if you're willing to retrain your IT operations crew, it's not likely that they will want to leave the Microsoft world where they are well paid and job-secure. Well, maybe I'm in a cheese bell, but I've never met an Azure/Microsoft IT person who would want to work with something else, and having been forced to work a little bit with it behind the scenes, I sort of get it... well not really.
Which boils down to why Microsoft has always been good with enterprise customers. The decision makers in your organisation will listen to everything, but their own IT departments will often sort of automatically recommend Microsoft products and at the end of the day, it'll all boil down to risk. Which is what Microsoft really sells... risk-mitigation. Sure their licenses are expensive, but is it really more expensive than losing your entire IT staff? (this isn't an actual question I'm asking, it's what goes through the considerations.)
This probably reflects my own prejudices, but it always struck me that MS based IT people wouldn’t work with anything else, basically because they couldn’t.
That stack optimises for not really having to understand what you’re doing, but also avoiding any major foot guns (and having the general arse covering that buying IBM used to provide, but which MS now does). The price you pay is that everything is horrible to work with. But if the alternative is not really being able to get anything done at all then so be it?
The Windows ecosystem does a lot of things that, to me, as a Linux/MacOS user, seem like a weird bunch of crazy decisions that are different just because.
Whether that's true or not, it does mean that a lot of people who came up on Windows IT don't have a mental framework for how to run or manage Linux systems. Likewise, when I'm trying to diagnose something on Windows it just seems like the entire thing is a disaster; where are event logs? In the event viewer! How do I filter them? It's a mess! Can I search them? Kind of! Do they have information to help me diagnose the problem? Almost never!
On Linux, I know all the tools I need to solve all the problems that come up; on Windows, I have only minimal concept of how things work, and very little way to diagnose or debug them when they go wrong, which is often.
For example, when my Windows gaming machine comes out of hibernation my ethernet controller insists that there's no connection. I can't convince it otherwise except by disabling the device and re-enabling it. I can't figure out where I might find information that tells me why this is happening, so I just wrote a powershell script to turn it off and then on again. I bet some Windows IT dork could figure it out in 30 seconds, but I'm a Linux IT dork and I have no clue.
> For example, when my Windows gaming machine comes out of hibernation my ethernet controller insists that there's no connection. I can't convince it otherwise except by disabling the device and re-enabling it. I can't figure out where I might find information that tells me why this is happening, so I just wrote a powershell script to turn it off and then on again. I bet some Windows IT dork could figure it out in 30 seconds
Windows and Linux dork here (heh). It has to do with how various computer manufacturers implemented the Sleep/Standby State (S3/S4), how they've resisted implementing a common standard at the hardware level, and how Microsoft eventually gave up arguing and patched around it with their own Modern Standby system in the S0 state.
https://learn.microsoft.com/en-us/windows-hardware/design/de...
Tbh, though, the only computer I've ever seen Hibernate work well on are Macs. Every x86 computer usually has some sort of issue with it, except for maybe business laptop models (eg HP's Elitebook line).
> ...an AI model will receive the applications, read them, auto-reply to irrelevant ones...
You're probably breaking EU law by building this nightmare.
https://artificialintelligenceact.eu/article/86/
All that law says is that the applicant 'shall have the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken.'
And even then, only if a job application rejection 'produces legal effects or similarly significantly affects that person in a way that they consider to have an adverse impact on their health, safety or fundamental rights'.
So as long as the company is recording the decisions taken and the reasons for those decisions, and providing those to candidates on request, they're in the clear.
I doubt that they are, but maybe!
If they're using a LLM to make those decisions, then they're fundamentally unable to provide the reasons for those decisions, because of how LLMs work.
Office used to work well on WINE. It was the switch to a rolling release model that killed it.
So that's what's keeping Microsoft from just running WINE on an MS-flavored Linux or perhaps a clean slate kernel as their next OS. I've been wondering for a while, this is by far the best explanation.
The Windows Kernel (and arguably the Windows APIs) are the only good part of Windows; they should dump everything else and run Linux above it; wait they did do that and then changed it to a boring VM.
if you rip out linux from your linux distribution you usually end up with GNU.
So, that would make this GNU/Windows
They could brand it as “New Windows”
Out with the old, in with the GNU.
> "running WINE on an MS-flavored Linux"
Like obsolete Longene project?
https://en.wikipedia.org/wiki/Longene
Parts of the OS were designed for Office. (Windows installer service, for example)
> Games are mostly just doing their own thing, only interacting with the system for input & output.
They should be trivial to port then, no?
Yeah but Windows is a more stable api to develop against than Linux (at least when it comes to stuff that games need to do) - it doesn't feel "pure", but pragmatically it's much better as a game developer to just make sure the Windows version works with proton than it is to develop a native Linux version that's liable to break the second you stop maintaining it.
As someone once said it best, Win32 is the only stable ABI on Linux: https://blog.hiler.eu/win32-the-only-stable-abi/
Because free software doesn't need such a thing as a stable ABI.
There does exist flatpak, everything that would benefit from a stable ABI could use that.
Yes, they are easy to port a lot of the time. Especially now because you can use DXVK to translate DirectX calls into Vulkan, so you don't need to write a Vulkan renderer. Input is sometimes a trickier one to deal with but a lot of the time games are using cross-platform libraries for that already!
Despite all this the Unity engine has spotty Linux support. Some games run better under Wine vs. Unity's native Linux builds. It's Vulkan renderer has had a memory leak for a while now. Input has randomly decided to double keypresses on some distros.
The hard part of Linux ports isn't the first 90% (Using the Linux APIs). It's the second 90%.
Platform bugs, build issues, distro differences, implicitly relying on behavior of Windows. It's not just "use Linux API", there's a lot of effort to ship properly. Lots of effort for a tiny user base. There's more users now, but proton is probably a better target than native Linux for games.
It’s not really about OS differences - as the GP said, games don’t typically use a lot of OS features.
What they do tend to really put a strain on is GPU drivers. Many games and engines have workarounds and optimizations for specific vendors, and even driver versions.
If the GPU driver on Linux differs in behavior from the Windows version (and it is very, very difficult to port a driver in a way that doesn’t), those workarounds can become sources of bugs.
The killer for games tends to be the anti-cheat or anti-piracy layers.
I have a Windows game I can't run under CrossOver (aka Wine 11) or a VM, only because its anti-piracy layer doesn't accept those circumstances.
Meanwhile I had to pirate Dark Souls 1 because Microsoft's own DRM prevented the legitimately purchased game from saving on Windows, and download official no-cd patches for two other games because their DRM stopped working.
The problem with DRM is the DRM.
For games, part of that mere „output” is 3d graphics, so replicating the internals of Direct 3D exactly right and getting the Linux GPU drivers to cooperate. That’s a hardcore task.
Fun fact: MS Office also uses Direct3D :) See "Graphics" requirement here: https://support.microsoft.com/en-us/office/system-requiremen... We put a ton of effort into D3D11 specifically to get MS Office running.
You're onto something but that's not entirely true for all games. There's plenty of vintage games, made before DirectX standardized everything into the late 90s, that don't work well under wine because back in their day, they would try to bypass windows by "hacking" their way to the hardware via unsupported APIs and hooks, to squeeze every bit of performance from the hardware, and also because every hardware vendor back then from graphics to sound shipped their own APIs.
You mean dos games, just run them under a dos emulator then.
Oh, no, before everything kind of converged to OpenGL and DirectX, there were oodles of different things trying to be the next graphics API.
There are the more obvious ones like 3DFX/Glide, but there was also stuff like the Diamond Edge 3D, which used Sega Saturn style "quads".
NO, I meant Windows games.
90s Windows ran inside of DOS, and you can run e.g. Windows 98 games (through Windows itself) in DOSBox. Look up exowin9x where they're trying to compile all of the necessary configs for one-click launchers.
I didn't think that regular DOSBox had support for stuff like 3dFX does it? Or other weird APIs?
I had to use PCem to get support for that stuff.
I tried running the elder scrolls Redguard, on wine, which launches windows version of dosbox with glide support. Redguard is a weird beast which is installed only with windows installer, but the actual game runs in dos mode
Everything works but the frame rate isn't great
If anyone knows a good Redguard setup for Linux please mail me, you can guess my mail easily. Now I just run the gog version
I've had some success with installing windows in dosbox-x which has glide support. Faster and more lightweight than pcem/86box
Then you can use dosbox-x which can run any non nt windows version and has support for 3d acceleration
Again, I meant windows games, not DOS games.
Windows before NT is just a dos app, and dosbox(-x) can play all windows games up to those which require ME.
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.
> 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.
Also a big part of the marketing for the SteamMachine/SteamDeck/SteamFrame is that it has a desktop mode and can be used like a pc, so i think they also have an interest in that
i didn’t buy a steam deck since so i can run Microsoft Office. i like that there’s freedom to open up desktop mode to tinker / install 3rd party software, but not to use it as a business machine.
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.
Although running Microsoft web apps are getting better.
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.
I don't know that they are. It's just there's more incentive to port stuff that has no direct alternative.
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.
> 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...
Yep. that's the route I tried before, no good, maybe it's just that the documentation is past it's sell by date, maybe it's lack of community use.. I'm just not seeing it. Even the article itself describes how to make an exe file... that will then work in Linux? Or is it simply a program that's easier to run on Wine? Loads of text with unclear details throughout it.
To make an elf, you use gcc. To make an exe, you use mingw.
The rest should be a matter of include and linker paths, but that's all I can recall right now.
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.
Wine devs do not want to work with people who have looked at ReactOS[0] (see at the end) so any collaboration is one-way (or by ignoring the guidelines) and the likelihood of the two projects merging is zero.
[0] https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...
Surprised no one responded to the 7th comment in that linked email thread, the author brought up a good point about making progress without using any disassembled windows binaries.
Very different projects so I would not encourage a merge but sharing a code base? I can totally see that being a boon for both and other Windows emulation projects.
ReactOS periodically rebases some of it's libraries from Wine.
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.
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.
Those aren’t the ones I am talking about. The global economy runs on Excel.
The EU seems to rapidly be adopting ODF, at least in official guidelines.
I simply wouldn’t have the patience to do what Elizabeth did, for a month, much less years. Really really impressive
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!
That's not boring at all. A lot of the works done in Wine can be fed back to ReactOS
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?
Yes, Microsoft does still sell MS Office 2024 as a one time purchase:
- https://www.microsoft.com/en-us/microsoft-365/p/office-home-...
- https://www.microsoft.com/en-us/microsoft-365/p/office-home-...
Outlook is a business exclusive these days?! Outlook used to be included in the most basic version of office back when I still used microsoft office.
I’ve only ever used Outlook when forced to by an employer and I find it a dreadful application to use. I would guess that most people prefer something else. I would imagine that most people tend to stick with the default email app on their computer (no idea what that is on Windows as I’ve managed to avoid having to use Windows for 7 years now).
The default mail app on Windows is now called Outlook for Windows, no relation to the Outlook in Office (sorry, Microsoft 365 Copilot), and it's a significantly worse barely functional webview. It also replaced the entire Calendar app, which was decent.
They've really shifted how Outlook works... as well as how the backend is more tuned to the way M365 mail works far more than how it used to work with Exchange, or independently. It's been a slow downslide imo since around 2007 or so.
I know the why, but it's really worse as an experience for most people than the older integrations... but the use of horizontally scalable backends makes for a saner platform at the expense of better UX.
Will be removed from the next release. Then you can’t connect to your own exchange server anymore and are forced into 365 when you want a desktop app.
Yes the do have an one time purchase option. You get 5 years of updates but no new features. I have it on my home computers. But new features are not a big deal since the differences are not big anymore (just like mobile phones.)
I wouldn't put it past Microsoft to suddenly add "features" that break said support.
"Office ain't done 'til Wine won't run"?
Ny that time office will be cloud only.
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.
Well about clean room, you almost got a haircut due to Google v. Oracle in the Android-Java API dispute
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
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.
And how would you determine that the buyer intends to play on linux, and not windows like 9x% of the buyers?
This extends past linux. Open source projects get used broadly regardless of runtime environment. Steam is just one open nerve ending where this could be used for good and they have the power to do so (and from what we've seen, steam seems to be a low friction company, less corpo red tape - would you trust say Ubisoft with handling this or steam?). If a game gets deployed to windows, it doesn't matter, as each game/application probably use five or ten or more open source projects regardless of where they run. It can help open source devs keep pacing with steam and game developer needs. Remember a ton of these project have upstream effects outside of gaming - its just the most obvious open nerve we can use to help open source.
You can only show the checkbox on Linux. You can add OS detection to the checkbox and have it say "support our $OS dependencies" and put that into different pots of money. You can make the checkbox say "support our Linux dependencies" and then rely on Windows people not selecting it.
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.
Oh absolutely, I would welcome some way of sponsoring such projects in general. I just meant to highlight that for this particular feature and project, there is already a form of sponsorship happening.
It’s a nice idea, but why not donate directly?
https://www.winehq.org/donate
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
> 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.
Yeah but to the commenter I was replying to, I don't think it was clear that detail was relevant to the benchmark numbers they were quoting.
Do they have any other usecase behind Wine? My guess would be MS SQL server, but is that correct?
Starting with SQL Server 2017, native Linux support exists. Probably because of Azure.
Ironically, SQL Server AFAIK in order to run on Linux uses what basically amounts to a Microsoft reimplementation of Wine. Which always makes me wonder if they'll ever get rid of Windows altogether someday in favour of using Linux + a Win32 shim. I think there are still somewhat strong incentives nowadays to keep NT around, but I wouldn't be that surprised it this happened sometime down the line.
It's a Windows container. It runs the NT kernel and a few minimal other things. The closest would be the Nano Server container
AFAIK it's more like a reimplementation of NT APIs in userspace - aka basically Wine with extra steps, or Linux UM. There was a slide deck going around about Project Drawbridge, here: https://threedots.ovh/slides/Drawbridge.pdf
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.
* 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.
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.
There's also Proton-GE [1], which is even more experimental and adds some bleeding edge fixes and features.
I've heard it's pretty good for fixing video playback/rendering (e.g. cutscene) issues if both the stable and the experimental branch of Proton can't make it work.
[1] https://github.com/GloriousEggroll/proton-ge-custom
A lot of what Proton-GE brings from my understanding is a larger support for Media Foundation, which can't be added to Proton itself because of license issues (Proton is from a commercial company, where Proton-GE is from an individual).
So aside from the stuff that has been implemented differently, running Proton instead of Proton GE is like trying to game on Windows N editions.
There is also UMU Launcher[0] which is basically all that without the Steam integration/dependencies so you can run games from GOG and other stores (it is a command-line tool but launchers like Heroic can use it behind the scenes). I used to install dxvk, etc manually but in recent months i switched to it as it tends to work much more seamlessly for games (i did disable its autoupdates though).
[0] https://github.com/Open-Wine-Components/umu-launcher
Though currently Proton has not yet shipped a release which uses Wine 11.
That makes sense. I thought they were entirely separate tbh but it makes sense that they'd share a lot of DNA.
I absolutely love my Ally running SteamOS. Incredible work by... everyone involved, really.
It's a distribution of Wine with some extra stuff added, importantly DXVK (directx => vulkan layer) and a lot of game specific workarounds.
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.
"Have fsync" is not a sufficient requirement. You need a kernel with windows-compatible fsync patches, and many distributions do not ship those.
Most people? What mainstream Linux distros ship without fsync or esync support?
Well I can tell you that if it didn’t make it upstream Fedora didn’t ship it.
It looks there was a copr for a custom kernel-fsync and projects like Bazzite or Nobara are adding patches.
From my understanding the fsync patches were never upstreamed.
The common gaming-focused Wine/Proton builds can also use esync (eventfd-based synchronization). IIRC, it doesn't need a patched kernel.
The point being that these massive speed gains will probably not be seen by most people as you suggest, because most Linux gamers already have access to either esync or fsync.
Maybe you are right about esync but anyway I would also gather a lot of people don’t have that either. At least personally I don’t bother with custom proton builds or whatever so if Valve didn’t enable that on their build then I don’t have it.
> if Valve didn’t enable that on their build then I don’t have it.
The Proton build is Valve's build. It supports both fsync and esync, the latter of which does not require a kernel patch. If you're gaming on Linux with Steam, you're probably already using it.
https://github.com/ValveSoftware/Proton/?tab=readme-ov-file#...
I thought you meant Proton-GE or such other patched builds of proton.
I would assume most of them? I'd be surprised if distros like Debian, Ubuntu, Fedora, etc. would ship non-mainline kernel features like that.
Sure, gaming-focused distros, or distros like Arch or Gentoo might (optionally or otherwise), but mainstream? Probably not.
Of course, esync doesn't require kernel patches, so I imagine that was more broadly out there. But it sounds like fsync got you performance pretty close to what ntsync can do, but esync was quite a bit behind both? With vanilla being quite a bit behind esync?
(Also, jeez, fsync, what a terrible name. fsync is a syscall that has to do with filesystem data. So confusing.)
> I would assume most of them? I'd be surprised if distros like Debian, Ubuntu, Fedora, etc. would ship non-mainline kernel features like that.
It's best not to assume with these things. With my stock Debian Stable kernel, Proton says this:
fsync: up and running.
And when I disable fsync, it says this:
esync: up and running.
> But it sounds like fsync got you performance pretty close to what ntsync can do, but esync was quite a bit behind both?
No, esync and fsync trade blows in performance. Here are some measurements taken by Kron4ek, who maintains somewhat widely used Wine/Proton builds:
https://web.archive.org/web/20250315200334/https://flightles...
https://web.archive.org/web/20250315200424/https://flightles...
https://web.archive.org/web/20250315200419/https://flightles...
> With vanilla being quite a bit behind esync?
Yes, vanilla Wine has historically fallen behind all of them, of course.
> Also, jeez, fsync, what a terrible name. fsync is a syscall that has to do with filesystem data. So confusing.
We can agree on this. :)
Last I checked, every distro of note had its own patchset that included stuff outside the vanilla kernel tree. Did that change? I admit I haven't looked at any of that in... oh, 15 years or so.
Depends on the distro.
Fedora looks like it carries a whooping 2 patches on top of upstream
esync and fsync both use mainline kernel features.
The article says fsync uses futexes which are a completely standard kernel feature.
If you read more carefully it says fsync needs some enhancements to the futex API, called futex2. The original patch that fsync needed called the syscall futex_wait_multiple. Eventually futex2 made it into the mainline kernel, but the syscall is called futex_waitv. Not sure if the wine fsync implementation was updated to support the mainline kernel futex2 implementation.
> 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.
> 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 really valuable CRUD monkeys are already domain experts as well. The threatened ones are junior developers whose output is barely better than AI slop.
> The really valuable CRUD monkeys are already domain experts as well
Sure but that’s a minority I’d argue. There wouldn’t be such a volume of shitty business software otherwise.
I will be interested to see if there are any economic effects of ending one of the last well paid, low barrier to entry careers in which some level of meritocracy was permitted.
> 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 -
I was seconding his point. I personally ended up in educational software which is CRUD-adjacent in terms of stress and sanity. Never regretted it.
ai slop
Looking at the user's other comments, I disagree.
Looking at your comments however, while probably not AI, they're still not helpful.
Never seen an LLM write so many short, halting sentences in a row. Very human.
You can tell from my comment that I'm not AI. I've had a lifelong habit of using commas instead of dashes in situations where the dashes would have been more appropriate. AI would always go for the dash.
First time I've been accused of AI.
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
Some people are exceptional at solving difficult but hard to explain problems while other are great solving direct business problems. No need to feel ashamed for both it’s just different work
I think your friend is just being kind.
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.
I work on OS/embedded and my wife in server backend. I definitely feel like a simpleton when trying to understand all of the high level stuff she works on. It doesn't invalidate my own expertise. There is nothing wrong with acknowledging someone has skills that you don't have and likely would take a long time to pick up.
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?...)
> how can you handle all that complexity?...
You don’t. Someone else smarter than you handled it already and you just need to integrate their solution.
"Someone else smarter than you manufactured microchips and you just need to integrate their solutions."
Yup. AbstractSingletonProxyFactoryBean and SimpleBeanFactoryAwareAspectInstanceFactory agree as well :)
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.
I met someone who bit shifts for life, uses opengl shaders for compute, but has no sql experience and is afraid of opening a tcp socket.
Trivial under plan9/9front. Under Win32/POSIX, run way.
On bit shifts, pick any Forth programmer and shaders will be almost like a toy for them. They are used to implement double numbers (and maybe floats) themselves by hand by just reusing the only integer numbers they have and writting custom commands to output these pairs of integer as double numbers. They can probably implement multithreading processing by hand in Forth and also know the IEEE standards for floats better than C programmers over 20 years.
Sure mate. And the guy who can do binary sums in his head would think of assembly as mere childsplay.
Jog on.
It was an example. Pedantry is alive and well on hn. :)
Thruth to be told, Dunning–Kruger effect is common among those who "shift bits" :)
I’m completely convinced I’m a dogshit programmer. You’re probably right.
bit shifting isn't impressive lol
Really?
I know literal kernel developers who can handle drivers and race conditions any day of the week who can't wrap their mind around Outlook, let alone GUI updates.
Myself. Forth it's easy, 9front C it's manageable but POSIX it's hell and managing both Unix descendants are a piece of cake.
GUI interfaces for the enterprise came from Dante's hell themselves. I hate them, they are like the Madhouse from that Asterix movie making satire of the European bureucracy of the day. The often are oddly designed and they are not documented at all, you must guess the meaning by chance of with a senior tutoring you.
The same with anything corporate from Microsoft with AD roles/group policies and the like. Or anything coming from IBM.
lol you guys are being too nice. Building CRUD apps is just implementing business logic by gluing APIs together, there is nothing to understand except the business domain, which is only done through exposure, because business logic is random. And then the APIs which are all essentially a kludge because of the shifting business logic.
Understanding low level code puts you on entirely different level because you can reason about a problem using logic and how systems operate.
No disrespect to any crud devs here but from my personal experience they just know a particular implementation of their domain and rarely even consider how the code base even operates as a whole
> lol you guys are being too nice. Building CRUD apps is just implementing business logic by gluing APIs together, there is nothing to understand except the business domain, which is only done through exposure, because business logic is random.
It isn't "random", a as business process develop over time to various business/customer/regulatory needs. The business process evolves over time typically.
When you take a business process, you are often formalising it. The fact that you have no appreciation of this, tells me you don't really understand what you are talking about.
> Understanding low level code puts you on entirely different level because you can reason about a problem using logic and how systems operate.
You have to do this in high level languages as well. It isn't something that only low level devs do. In fact to be able to write any good code you need to understand the problem domain.
> No disrespect to any crud devs here but from my personal experience they just know a particular implementation of their domain and rarely even consider how the code base even operates as a whole
You are literally disrespecting them by saying this. It is also false, what you are describing is developers having deal with incomplete/poor specifications and poor documentation. BTW this is rampant through the industry. I wanted to do some stuff yesterday with Docker and Go, the documentation is non-existant.
Everything is shit, it's just different kinds of shit. :)
No not really. I've worked with good teams and you would be amazed at how easy it is, even with iffy tech stacks. Stuff even get documented properly.
Kernel developers know that, eventually, they'll figure out how the system works and is supposed to work.
CRUD developers know that they never, ever will, because business logic is insane.
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.
interesting, how did you manage the db interactions in c++? and did you have a single executable for the app and the web server combined?
no database for this project - the data model has a simple text representation so it gets serialized out to a folder/file layout on disk that goes into version control. single self-contained binary: contains the web/websockets server, backend logic, parser/serialization. there is a separate component in python that sits behind an internal network connection to handle an execution sandbox.
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.
Don't feel too bad - I had to Google what CRUD means. :D
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.
If it's any consolation I can out-imposter you: lately I've been mostly reviewing LLM-generated code.
Same. I feel like a plumber compared to real engineers.
Engineers & architects leave a lot of detail out of their designs, relying on the plumbers and other trades to figure out the Right Thing. (-:
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 feel like plumbers compared to the plumbers
Play with low level things. It'll help you in your daily job in ways you do not yet imagine. Start here: nandgame.com
>People are dealing with such low level things, while i'm outta here building simple CRUDs.
CRUDs do pay the bills.
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.
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.
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.
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.
I've experienced multiple instances where (so I heard; I don't use Windows) a Windows Update completely broke a game on Windows for everyone, but Wine/Proton kept running it just fine. So we're already there in some sense.
I remember when the shader caching done for a popular game in linux made that game run better than the windows version
It feels like it won't be long before Microsoft starts helping with that (by making Windows less stable, not improving Wine).
What I wonder about is if MS wants to keep people on windows, what methods they can use to do that. For simple desktop stuff I don't think they have many options to lock in other developers (and their audiences) to windows unless they want do so themselves (putting aside web based or not PC-desktop).
Bleeding edge gaming and multiplayer anti-cheat is one area where I think having a big company owning the OS probably helps them stay ahead, as that structure probably lets them work with hardware designers to get the capabilities in use (i.e. in new versions of DirectX) and available to software developers first. There's generally a lag in adoption for new features within Vulkan and then usage downstream in wine/proton to get compatibility parity with windows, then the games themselves being able to run feature/performance parity. It'd be interesting to see what cooperation would be needed to have the linux gaming stack equal at the point new features are released, and with the least amount of manual hacks or command line tweaking required for the users. As discussed a few weeks back, tough anti-cheat for linux seems like a paradox with the current methods.
> What I wonder about is if MS wants to keep people on windows, what methods they can use to do that
Microsoft doesn't give a fuck about private customers any more. They don't have money.
What has money though is enterprise/government sales, and MS got these customers tightly locked in. Compliance audits and tooling for insurances or legal stuff (SOX, GDPR, ...) are built against a full Microsoft stack of MS Server, Active Directory, Azure, Teams, Office 365 and Windows desktops.
You might be able to get away with replacing AD and GPO with Samba servers but even that is already a pain when the auditors come knocking. Everything else? There is no single FOSS based "standard offering" (i.e. a combination of everything needed to run an on-prem enterprise site, Office replacement, remote collaboration tooling), so every audit for such setups must be custom made and involves a lot of extra work.
A second leg is industrial control machines, medical devices and the likes. That's all stuff built by third party vendors and integrators. They need to continue on Windows because switching to an alternative OS would require redoing everything from scratch on the software and certification side. These customers buy the LTSC IoT stuff.
And that is why you see Microsoft pushing enshittification so hard on private customers... extract the last few cents you can from them. But the real money comes from the large customers.
Windows 14 will just be a linux distro with wine acting as backwards compatibility.
Why would Microsoft ever do that?
WSL is already there for the folks that want to play with Linux.
For a while it seemed like Microsoft wasn't taking Windows seriously as a product. And the easiest way to cut costs on that is to use a solution someone else is building and maintaining. They did retire Internet Explorer in favor of a Chromium browser, so it wouldn't be unprecedented.
Inb4 Windows 40k and to run the "kernel" you need to sacrifice 1000 a day
By the time we get to version 40k the kernel will just be AI hallucinating a UI for you at 60fps.
Secondly, I do acknowlege your 40k reference.
Wine actually does run some ancient Windows games better than Windows 11 itself.
It certainly runs 16-bit Windows games better than Windows 11, which can't run them at all. Not that there are a ton of those, but it's still pretty neat that they work.
Time to dust off my cd copy of Stars! (From the disk backup, the cd had terminal illnesses and has died). The only win16 game I've ever seen distributed on CDROM. Wine already ran it ok (iirc there were some issues but nothing gamebraking), but now it can do so without i386 libs.
16-bit software won't run natively in 64-bit mode. It requires some programmatic emulator, like DosBox. Or am I missing something?
The thing that you're missing is that Microsoft used to ship that emulator with Windows. Then they stopped doing that.
AFAICT, Wine can run WIN16 programs. I don't know if it can run DOS programs. There's a WineHQ wiki page that says it can load DOS programs, but various internet fora seem to believe that Wine's DOS support is pretty broken. I've never tried it, and have no DOS programs handy, so I can't verify those claims.
"DOS support" is tricky inasmuch as a lot software from that era - especially larger and more complex packages - interacted with hardware directly. In a sense, they weren't really DOS applications so much as they were bare-metal PC applications which were booted from DOS. It'd be difficult for WINE to support those, and other projects like DOSbox / 86box / etc do a better job of it.
Not just ancient games!
https://arstechnica.com/gaming/2025/06/games-run-faster-on-s...
MS got such a black eye for that that they're developing a build of windows specifically for handhelds, optimized, without the bloat and power hungry extras. Would be nice if it ran on laptops
Wine is also the reason why Windows software has more longevity on Mac than Mac software. Like, 32-bit didn't get deprecated in Wine.
Anything Direct Draw related will be mapped into OpenGL under Unix giving you decent speeds. On Windows it will be a crawling slideshow because from Windows 8 and up it will use a really dog slow software mode with no acceleration at all, worse than plain VESA. Yes, you can reuse WineD3D DLL's on Windows and run these game in a fast way, but not by default, it's a Win32 port of some Wine libraries.
Once I had to use a Mesa3D build for Windows and use the zink driver to render OpenGL to Vulkan, otherwise it would use Windows' software renderer.
I had to use WineD3D's ddraw.dll among another one to run these touch based arcade machine games with card games, Trivial Pursuit, hangman and the like. If not the game made for w98/2k would really lag even under an i3.
The same with some multimedia CD's from its day. Scummvm it's partially implementing Macromedia Director support but the mentioned game had a custom engine. The Scummvm devs would RE in few weeks (it's a simple 2D game bundle, nothing difficult, with virtually no animations, almost everything it's still images) but no one began yet.
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.
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.
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.
People always say this to shit on glibc meanwhile those guys bend over backwards to provide strong API compatibilities. It rubs me off the wrong way.
What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.
Such application could be rebuilt to work with an older glibc as the API is stable. The ABI is not which is why the application would need to be rebuilt.
glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed. Maintaining a stable ABI mostly helps proprietary software where the source is not available for recompilation. Naturally the gnu guys building glibc don’t care about that use case much.
I guess you didn’t mention glibc in your comment but I already typed this out
> What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.
Is this correct? I think you perhaps have it backward? If I compile something against the glibc on my system (Debian testing), it may fail to run on older Debian releases that have older glibc versions. But I don't see why an app built against glibc 2.12 wouldn't run on Debian testing. glibc actually does a good job of using symbol versioning, and IIRC they haven't removed any public functions, so I don't see why this wouldn't work.
More at issue would be the availability of other dependencies. If that old binary compiled against glibc 2.12 was also linked with, say, OpenSSL 0.9.7, I'd have to go out and build a copy of that myself, as Debian no longer provides it, and OpenSSL 3.x is not ABI-compatible.
> glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed.
If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux. And I wouldn't blame them.
I don't know what the official policy is, but glibc uses versioned symbols and certainly provides enough ABI backward-compatibility that the Python package ecosystem is able to define a "manylinux" target for prebuilt binaries (against an older version of glibc, natch) that continues to work even as glibc is updated.
Sorry I am not sure if 2.12 is a a recent release or older, I made up this number up
If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work
>If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux.
Not really a show stopper, vendors just do what vendors do and bundle all their dependencies in. Similar to windows when you use anything outside of the win32 API.
The only problem with this approach is that glibc cannot have multiple versions running at once. We have “fixed” this with process namespaces and hence containers/flatpak where you can bundle everything including your own glibc.
Naturally the downside is that each app bundles their own libraries.
The only problem with this approach is that glibc cannot have multiple versions running at once
that's not correct. libraries have versions for a reason. the only thing preventing the installation of multiple glibc versions is the package manager or the package versioning.
this makes building against an older version of glibc non-trivial, because there isn't a ready made package that you can just install. the workarounds take effort:
https://stackoverflow.com/questions/2856438/how-can-i-link-t...
the problem for companies developing on linux is that it is not trivial
glibc must match the linker so you would need a separate linker and the binaries usually have a hardcoded path to the system linker (and you need to binary patch the stuff - https://stackoverflow.com/questions/847179/multiple-glibc-li...)
So in practice you can only have 1 linker, 1 glibc (unless you do chroot or containers and at that point just build your stuff in Ubuntu 12.04 or whatever environment)
You compile in a container/chroot with the userspace you target. Done.
In the context of games, that will likely be Steam Runtime.
it's not that simple. you want to be able to use a modern toolchain (compilers that support the latest standards) but build a binary that runs on older systems.
the only way to achieve that is to get the older libraries installed on a newer system, or you could try backporting the new toolchain to the older system. but that's a lot harder.
It may be hard-ish, sometimes. Sometimes it's a breeze. And sometimes you can just use host's toolchain with container's sysroot and proceed as if you were cross-compiling. Most of the time it's not a big deal.
MUSL is a better libc for companies making proprietary binaries. They can either statically link it, or provide a .so with the musl version they want their programs to use & dynamically link that.
I personally believe we should just compile games statically. Problem solved, right?
This a toolchain issue rather than OS issue. This wounldn't have been a problem if gcc/clang just took a --stdlib-version option and built the executables linking to that version of glibc or equivalent.
I am sorry, I did not mean to imply anyone else is doing something poorly. I believe glibc's (and the rest of the ecosystem of libraries that are probably more limiting) policies and principled stance are quite correct and overall "good for humanity". But as you mentioned, they are inconvenient for a gamer that just wants to run an executable from 10 years ago (for which the source was lost when the game studio was bought).
that 10 year old binary should run, unless it links against a library that no longer exists.
for example here is a 20 year old binary of the game mirrormagic that runs just fine on my modern fedora machine:
ok, there are some issues: the sound is not working, and the resolution does not scale. but there are no issues with linked libraries.No other operating system works like this. Supporting older versions of an OS or runtime with a compiler toolchain a standard expectation of developers.
Plenty of operating systems work like this. Just not highly commercial ones because proprietary software is the norm on those.
From a bit of research it looks like FreeBSD for example only provides a stable ABI within minor versions and I imagine if you build something for FreeBSD 14 it won’t work on 13.
Stable ABI literally only benefits software where the user doesn’t have the source. Any operating system which assumes you have the source will not prioritize it.
(Edit: actually thinking harder MacOS/iOS is actually much worse on binary compatibility, as for example Intel binaries will stop working entirely due to M-cpu transition - Apple just hits developers with a stick to rebuild their apps)
> Stable ABI literally only benefits software where the user doesn’t have the source
Stable ABI benefits everyone. If I need to recompile a hundred packages with every OS update instead of doing real work then there's something seriously wrong with my OS.
Yes, and this is a great reason why FreeBSD isn't a popular gaming platform, or for proprietary software in general. I'm not saying this is a bad thing, but... that's why.
> Stable ABI literally only benefits software where the user doesn’t have the source.
It also benefits people who don't want to have to do busywork every time the OS updates.
FreeBSD isn't too bad, you can build/install compat packages back to FreeBSD 4.x, and I'd expect things to largely work. At previous jobs we would mostly build our software for the oldest FreeBSD version we ran and distribute it to hosts running newer FreeBSD releases and outside some exceptional cases, it would work. But you'd have to either only use base libraries, or be careful about distribution of the libraries you depend on. You can't really use anything from ports, unless you do the same build on oldest and distribute plan.
At Yahoo, we'd build on 4.3-4.8, and run on 4.x - 8.x. At WhatsApp, I think I remember mostly building on 8.x and 9.x, for 8.x - 11.x. The only thing that I remember causing major problems was extending the bitmask for CPU pinning; there were a couple updates where old software + old kernel CPU pinning would work, and old software + new kernel CPU pinning failed; eventually upstream made that better as long as you don't run old software on a system with more cores than fit in the bitmask. I'm sure there were a few other issues, but I don't remember them ...
You can still run x86 binaries on new macbooks. They don't stop working entirely. Using wine I can even run x86 windows binaries.
They announced Rosetta 2 will be deprecated and eventually removed (MacOS 28?)
By that point they already hit the developers enough to get them to port to aarch64
(arguably though this could be a special case because it is due to architectural transition)
Apple said they will keep Rosetta 2 for select usecases, such as gaming. They do have a user base that uses Steam and bought mac games - without rosetta that would mean the users could no longer play their game. And no one ports 5-10year old games.
Can one run a windows version of a game well over on say, a MBP?
I ask because my current laptop is getting long in the tooth, and if I were just buying it for productivity stuff, the current MBPs are beasts, but last time I checked years ago, gaming on os x was in a sad state, even compared to linux.
Crossover works wonders. Currently playing Hogwarts Legacy from the Epic Store on my Macbook M4 Pro on 1080p in Medium with a PS5 controller
what about mac os?
macOS doesn't require developers to rebuild apps with each major OS release, as long as they link with system libraries and don't try to (for example) directly make syscalls.
Apple may require rebuilds at some point for their Mac Store (or whatever they call it), but it's not required from a technical perspective.
The one exception here is CPU architecture changes, and even then, Apple has provided seamless emulation/translation layers that they keep around for quite a few years before dropping support.
The latest Xcode supports targeting back to macOS 11. This covers >99% of macs which is acceptable for most developers.
https://developer.apple.com/support/xcode/
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."
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.
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.
Maybe, but the incentive runs the other way. If Windows compatibility gets good enough, game devs have even less reason to pay for Linux QA and support, and Valve plus GPU vendors can live with that because the cost gets pushed onto Wine and Proton chasing Windows' quirks forever with hacks and syscall glue.
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
Not really. I actually tried building an "old" game (read: not updated since 2014 or so) on Linux when I used it. It didn't work because autotools changed, some weird errors with make, and the library APIs have changed too.
In the end I gave up and just used proton on the windows .exe. Unbelievable. :(
I should clarify my original comment about stability only applies to glibc itself. Once we go out of glibc there will be varying degrees of API/ABI stability simply because at that point it’s just different groups of people doing the work
In some cases such libraries are also cross-platform so the same issues would be found on Windows (eg: try to build application which depends on openssl3 with openssl4 and it will not work on either Linux or windows)
For future reference if you ever need to do that again, it would be way easier to spin up a container with the build environment the software expects. Track down the last release date of the software and do podman run —-rm -it ubuntu:$from_that_time and just build the software as usual.
You can typically link the dependencies statically during build time to create system independent binaries. So the binary produced inside the container would work on your host as well.
Even if all games were FOSS, without - at least - a stable API, most games will remain a hassle to run. DOOM doesn't deal as much with this due to the high amount of volunteers, but relying on community support for all games is just outsourcing labor to some unlucky fellows. At best, it's yet another pain for Linux users. At worse, it's the death of unpopular games. Either case, a hurdle for Linux adoption.
> Proprietary software needs a stable ABI.
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
People who keep parroting this clearly have no experience of gaming on linux.
I am playing both modern and old games on Linux. Games outside a super narrow enthusiast realm are always closed-source (even indie ones) and it's going to stay like that in the foreseeable future, that's just a fact of life and gamedev incentives and specifics.
Please elaborate.
Wine has constant regressions. What works fine today will completely fail next year. Which is why steam lets you pick which proton version you want to use.
Which means that a .exe without the exact version of wine won't run.
Plus of course there's the whole vulkan stuff. Older cards aren't well supported but it will rather crash than just run openGL normally where it would work fine.
In practice, Wine is constantly improving. It's in active development and not that stable, but regressions are mostly local. Treat its releases like bleeding edge.
>What works fine today will completely fail next year.
Usually not on the timescale of a year. I have many new games that worked a year ago and none of these stopped working now. The worst breakage I had recently was some physics glitches in an old RPG (released in 2001) on Wine 11.0, and it was fixed in the next release.
Those issues seem othorgonal to stable ABI issue from OP, specially the OpenGL one (that is more like a hardware incompatibility issue). When apps fail to run due to Wine updates, they are considered bugs to be fixed. On the native side, apps may break becuase: 1) required library is unavailable, normally because it is too old and unsupported; 2) required library's path is different in distro A from B. None of these are considered bugs and, as such, are rarely addressed. I believe Steam Linux Runtime is an attempt at fixing this,but I'm not sure about its effectiveness. Also, you are exaggerating on the "exact Wine version". It helps to know which versions don't have a regression by knowing which specific version an app used to run on.
> I believe Steam Linux Runtime is an attempt at fixing this,but I'm not sure about its effectiveness.
It's effective enough for it to be practically a solved problem now.
Are you able to run any of the old Loki games on Linux these days?
With compat libraries and OSSPD it will run even under Pulseaudio.
In many cases for game devs/publishers "supporting Linux" now means making sure the Windows build runs well under Proton.
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.
There always will be old games that will never be ported to Linux.
Quiet the other way around. Wine being good will reduce incentives for game studio to produce native Linux ports.
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.
Could there ever be a killer app for Linux? One that would cause a not-insignificant number of people to decide that Linux was worth switching to, even if there was some pain of moving away from Windows?
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.)
If I had a guarantee that every windows application that is important to me runs on Wine I would switch next day. Now I use Windows to develop both - Windows and Linux applications even when primary running mode for application is business backend on Linux
It'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.
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.
32 bit game with 16 bit installer has a lot of examples, to the point that Windows has workarounds for common installers.
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.
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.
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 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.
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 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.
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.
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.
People such as Figura and Bertazi have been attempting to do what you propose for most of a decade now[1]. They've ended up with this, after two previous implementations running in Wine for many years. Thier reasons are explained in their documentation[2]. Perhaps you know better. We all look forward to your work.
[1] https://lkml.org/lkml/2019/7/30/1399 [2] https://docs.kernel.org/userspace-api/ntsync.html
> 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
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.
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?
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.
If someone is interested in hearing the author Elizabeth Figura's views on Wine and Proton: https://www.youtube.com/watch?v=ZNBKTolL5oQ
I wish competitive shooters (or rather their anti-cheats) would run on Linux. Only reason left to use Windows.
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.
Linux native semaphores are enough. Linux has been able to be very performant without it. That feature seems like way too over engineered for little gains.
This comes up often, but what can it do that poll can't?
Reading the link provided by https://news.ycombinator.com/item?id=47511778, I believe "atomically acquire multiple objects". The link states they try to emulate it by performing a poll then a read, but the gap between those results in a race, which is a terrible thing to have in a synchronisation primitive.
There was also something about needing to back out if any of the reads fails to acquire, which also sounds nasty.
Great post.
Ah, interesting, so wfm does both the wait and the acquire!
When using eventfd it is indeed annoying having to both poll and later read to disarm the object (there are epoll tricks that can be used but are not generalizable).
The signal+wait is also a primitive that it is hard to implement atomically on posix.
awesome, finally wine is getting proper ntsync support... and i reckon wow64 will let me run so many old games...
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]
Running most of my VSTs with wine + yabridge. Amazing that transcription layer/emulation software end up having less issues than running shit native.
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...
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/
The story was picked and featured autonomously by the rabbit hole agentic show - https://www.youtube.com/watch?v=rWQRmasdSu0
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.
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.
That’s a wild exaggeration. Yes they underperform relative to the Windows drivers but my experience is far from “cutting framerates in half” nor “borderline impractical”. I’ve had the last four generations of Nvidia card (currently on 5070Ti) on Linux and played demanding games just fine.
This is not true at all. I game on Linux (Arch, btw) on my 3090 and every game not using some kind of kernel-level anticheat just works. I have never made formal comparisons, but my experience is that I can't notice a difference in performance relative to Windows most of the time. One exception was Helldivers 2, but the performance gap has more or less closed recently with recent Proton versions.
The only problem with Nvidia in the last... 5 years was their wayland support and their worse than expected performance for DX12 games. Both of which were being actively worked on, where wayland support has been improving since 2 years ago and DX12 performance needs patches on all the stack, the driver is there, mesa and vkd3d patch are pending.
In practically every benchmark the Linux Nvidia drivers notably underperform compared to the windows driver.
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.
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?
Anybody know if NTSYNC support is why the Chrome OS team moved away from native Steam support?
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…
> 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.
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
“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'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
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.
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?
For someone gaming on linux, is proton or wine currently ahead on the virtualization side?
Can we finally ditch windows ?
> 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.