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).
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.
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.)
What I wonder about is if MS wants to keep people on windows, what methods they can use to do that. For simple desktop stuff I don't think they have many options to lock in other developers (and their audiences) to windows unless they want do so themselves (putting aside web based or not PC-desktop).
Bleeding edge gaming and multiplayer anti-cheat is one area where I think having a big company owning the OS probably helps them stay ahead, as that structure probably lets them work with hardware designers to get the capabilities in use (i.e. in new versions of DirectX) and available to software developers first. There's generally a lag in adoption for new features within Vulkan and then usage downstream in wine/proton to get compatibility parity with windows, then the games themselves being able to run feature/performance parity. It'd be interesting to see what cooperation would be needed to have the linux gaming stack equal at the point new features are released, and with the least amount of manual hacks or command line tweaking required for the users. As discussed a few weeks back, tough anti-cheat for linux seems like a paradox with the current methods.
> What I wonder about is if MS wants to keep people on windows, what methods they can use to do that
Microsoft doesn't give a fuck about private customers any more. They don't have money.
What has money though is enterprise/government sales, and MS got these customers tightly locked in. Compliance audits and tooling for insurances or legal stuff (SOX, GDPR, ...) are built against a full Microsoft stack of MS Server, Active Directory, Azure, Teams, Office 365 and Windows desktops.
You might be able to get away with replacing AD and GPO with Samba servers but even that is already a pain when the auditors come knocking. Everything else? There is no single FOSS based "standard offering" (i.e. a combination of everything needed to run an on-prem enterprise site, Office replacement, remote collaboration tooling), so every audit for such setups must be custom made and involves a lot of extra work.
A second leg is industrial control machines, medical devices and the likes. That's all stuff built by third party vendors and integrators. They need to continue on Windows because switching to an alternative OS would require redoing everything from scratch on the software and certification side. These customers buy the LTSC IoT stuff.
And that is why you see Microsoft pushing enshittification so hard on private customers... extract the last few cents you can from them. But the real money comes from the large customers.
It certainly runs 16-bit Windows games better than Windows 11, which can't run them at all. Not that there are a ton of those, but it's still pretty neat that they work.
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.
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.
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.
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
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'd like to see would be some useful extra APIs in Wine, that would allow it to perform even better in some situations, and that such APIs would be then embraced by the game developers.
Finally some embrace, extend, and extinguish love right back at Microsoft!
People always say this to shit on glibc meanwhile those guys bend over backwards to provide strong API compatibilities. It rubs me off the wrong way.
What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.
Such application could be rebuilt to work with an older glibc as the API is stable. The ABI is not which is why the application would need to be rebuilt.
glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed. Maintaining a stable ABI mostly helps proprietary software where the source is not available for recompilation. Naturally the gnu guys building glibc don’t care about that use case much.
I guess you didn’t mention glibc in your comment but I already typed this out
No other operating system works like this. Supporting older versions of an OS or runtime with a compiler toolchain a standard expectation of developers.
Plenty of operating systems work like this. Just not highly commercial ones because proprietary software is the norm on those.
From a bit of research it looks like FreeBSD for example only provides a stable ABI within minor versions and I imagine if you build something for FreeBSD 14 it won’t work on 13.
Stable ABI literally only benefits software where the user doesn’t have the source. Any operating system which assumes you have the source will not prioritize it.
(Edit: actually thinking harder MacOS/iOS is actually much worse on binary compatibility, as for example Intel binaries will stop working entirely due to M-cpu transition - Apple just hits developers with a stick to rebuild their apps)
Yes, and this is a great reason why FreeBSD isn't a popular gaming platform, or for proprietary software in general. I'm not saying this is a bad thing, but... that's why.
> Stable ABI literally only benefits software where the user doesn’t have the source.
It also benefits people who don't want to have to do busywork every time the OS updates.
FreeBSD isn't too bad, you can build/install compat packages back to FreeBSD 4.x, and I'd expect things to largely work. At previous jobs we would mostly build our software for the oldest FreeBSD version we ran and distribute it to hosts running newer FreeBSD releases and outside some exceptional cases, it would work. But you'd have to either only use base libraries, or be careful about distribution of the libraries you depend on. You can't really use anything from ports, unless you do the same build on oldest and distribute plan.
At Yahoo, we'd build on 4.3-4.8, and run on 4.x - 8.x. At WhatsApp, I think I remember mostly building on 8.x and 9.x, for 8.x - 11.x. The only thing that I remember causing major problems was extending the bitmask for CPU pinning; there were a couple updates where old software + old kernel CPU pinning would work, and old software + new kernel CPU pinning failed; eventually upstream made that better as long as you don't run old software on a system with more cores than fit in the bitmask. I'm sure there were a few other issues, but I don't remember them ...
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.
> 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.
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.
> What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.
Is this correct? I think you perhaps have it backward? If I compile something against the glibc on my system (Debian testing), it may fail to run on older Debian releases that have older glibc versions. But I don't see why an app built against glibc 2.12 wouldn't run on Debian testing. glibc actually does a good job of using symbol versioning, and IIRC they haven't removed any public functions, so I don't see why this wouldn't work.
More at issue would be the availability of other dependencies. If that old binary compiled against glibc 2.12 was also linked with, say, OpenSSL 0.9.7, I'd have to go out and build a copy of that myself, as Debian no longer provides it, and OpenSSL 3.x is not ABI-compatible.
> glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed.
If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux. And I wouldn't blame them.
Sorry I am not sure if 2.12 is a a recent release or older, I made up this number up
If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work
>If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux.
Not really a show stopper, vendors just do what vendors do and bundle all their dependencies in. Similar to windows when you use anything outside of the win32 API.
The only problem with this approach is that glibc cannot have multiple versions running at once. We have “fixed” this with process namespaces and hence containers/flatpak where you can bundle everything including your own glibc.
Naturally the downside is that each app bundles their own libraries.
The only problem with this approach is that glibc cannot have multiple versions running at once
that's not correct. libraries have versions for a reason. the only thing preventing the installation of multiple glibc versions is the package manager or the package versioning.
this makes building against an older version of glibc non-trivial, because there isn't a ready made package that you can just install. the workarounds take effort:
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.
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)
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.
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 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).
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 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.
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.
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.
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?
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
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.
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 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.
It seems more likely to me that the Windows API will become the de-facto Linux gaming SDK, and the idea of porting a game to Linux will become meaningless.
If I had a guarantee that every windows application that is important to me runs on Wine I would switch next day. Now I use Windows to develop both - Windows and Linux applications even when primary running mode for application is business backend on Linux
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.
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.
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.
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.
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 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.
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?...)
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.
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’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.
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.
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.
> 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.
Why do people belittle CRUDs? Or even call them that? I have written quite a few applications, where there was a frotend which displayed things stored in a SQL db, with certain operations allowing you to modify said db, which I guess would fall into the CRUD variety, but the least of the complexity, and usefullness lay in that fact.
Plenty of business apps don't really ask for much more than that, and those are the CRUD apps. They're not particularly challenging to write, nor is it very interesting to do so.
I am 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.
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
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).
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.
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.
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.
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.
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.
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.
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.)
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.
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
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.
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.
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.
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.
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.
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
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.
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?
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.
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.
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.
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.
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.
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.
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?
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.
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.
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!
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.
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.
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'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..
> 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?
> 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.
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 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.
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.
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.
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'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.
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.
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.
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.
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.
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.
Before anyone gets too excited about ntsync, the performance gains are (with few exceptions) mild, usually in the lower single percentage range. These extreme gains are the result of benching against vanilla wine without fsync, anyone playing demanding games on linux would have been doing so using fsync. This is mentioned in the article but treated like a side note. I've been running benchmarks between both and while the performance increase is real, please temper your expectations. A few titles might also run slightly worse.
The common gaming-focused Wine/Proton builds can also use esync (eventfd-based synchronization). IIRC, it doesn't need a patched kernel.
The point being that these massive speed gains will probably not be seen by most people as you suggest, because most Linux gamers already have access to either esync or fsync.
Maybe you are right about esync but anyway I would also gather a lot of people don’t have that either. At least personally I don’t bother with custom proton builds or whatever so if Valve didn’t enable that on their build then I don’t have it.
> if Valve didn’t enable that on their build then I don’t have it.
The Proton build is Valve's build. It supports both fsync and esync, the latter of which does not require a kernel patch. If you're gaming on Linux with Steam, you're probably already using it.
I would assume most of them? I'd be surprised if distros like Debian, Ubuntu, Fedora, etc. would ship non-mainline kernel features like that.
Sure, gaming-focused distros, or distros like Arch or Gentoo might (optionally or otherwise), but mainstream? Probably not.
Of course, esync doesn't require kernel patches, so I imagine that was more broadly out there. But it sounds like fsync got you performance pretty close to what ntsync can do, but esync was quite a bit behind both? With vanilla being quite a bit behind esync?
(Also, jeez, fsync, what a terrible name. fsync is a syscall that has to do with filesystem data. So confusing.)
Last I checked, every distro of note had its own patchset that included stuff outside the vanilla kernel tree. Did that change? I admit I haven't looked at any of that in... oh, 15 years or so.
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.
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.
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.
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 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.
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.
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.
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?
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 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 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.
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.
If you're interested in technical notes on how the WoW64 thing works, I dug into Wine and implemented a similar thing in my (far inferior) emulator and wrote about it here, including some links to some Wine resources: https://neugierig.org/software/blog/2023/08/x86-x64-aarch64....
Hey thanks! I don't mean to hijack this great wine news with my own project, but since you asked, the top of the post has links to more. I will fix the link.
> This 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.
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.
Not to sound snarky, but now please get it to run Microsoft Office. I'd argue that this is the last barrier to many, many people being able to use Linux full-time for business purposes.
If you really / actually want Linux and Linux Gaming to really take off, contribute with whatever helps to get Office 365 running in Linux without a VM.
Like it or not, the business world runs on Office.
I have quite a few machines under my direction, and I would drop Windows on every single one of them for employees that have never used Linux in their lives if I could be assured that they had Office and Teams.
I don't know if it is. Most businesses seem to use the web-based Office365 interface now, rather than native Office.
I expect the biggest reasons businesses use Windows these days are momentum, and lower support costs (Linux is still less reliably than Windows on real laptop hardware).
I work in an area where large heavy collaborative Word documents are very commonplace.
I've tried very much to make this work on Linux with the web apps, but they're just not good enough - not feature complete, and quite slow and clunky compared to the native equivalent.
I don’t think so. Windows is very easy to administer compared to both, Linux and Mac. There is also a compliance part that MS makes easier, though it’s a bit beyond what I really know.
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?
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]
Support for Xbox Game Pass games (typically deployed as UWP / containerized) would be absolutely amazing and likely the final nail in the coffin for Windows for gaming for many people.
I 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...
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.
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).
> 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.
kapija | a day ago
dinkblam | 23 hours ago
https://github.com/Alien4042x/Wine-NTsync-Userspace-macOS-ba...
yjftsjthsd-h | 23 hours ago
kelnos | 21 hours ago
hungryhobbit | 22 hours ago
I mean, I know Mac has had some great games (eg. I spent so much time on school Macs playing that Bolo tank game) ... but they have probably <1% of the number of games Windows has. I'd expect a simiilar percentage of devs to be interested in Mace (or whatever you call Mac Wine).
kelnos | 21 hours ago
ticulatedspline | 23 hours ago
jfaulken | 23 hours ago
p_ing | 23 hours ago
ssl-3 | 21 hours ago
OS/2 may have been a better Windows than Windows during the Warp days 30-ish years ago. It was also a very competent operating system in its own right.
We all know the story:
It never had a broad base of native applications. It could have happened, but it did not happen. Like, back then when Usenet was the primary way of conducting written online discourse, the best newsreader I had on OS/2 was a Windows program; the ones that ran natively on OS/2 weren't even close.
And OS/2 never had support from a popular company. There were times at OS/2's peak (such as it was) when it was essentially impossible to buy a new computer with OS/2 pre-installed and working correctly even from IBM.
Linux, though? Over those same 30-ish years, a huge amount of native applications have been written. Tons of day-to-day stuff can be done very well in Linux without even a hint of Wine and that's been reality for quite a long time now.
The missing piece, if there is one, is gaming. It'd be great to have more native games and fewer abstraction layers. But systems like Valve's popular Steam Deck and upcoming Steam Machine are positive aspects that OS/2 never had an equivalent to. And since Steam is very nearly ubiquitous, companies that sell computer game software do pay attention to what Valve is doing in this space.
(And frankly, when a game runs great in some Steam/Wine/Proton/Vulkan shapeshifting slime mold abstraction stack, I really do not care that it isn't running natively. I push the button and receive candy.)
krastanov | 23 hours ago
TehCorwiz | 23 hours ago
carlos_rpn | 23 hours ago
keyringlight | 23 hours ago
Bleeding edge gaming and multiplayer anti-cheat is one area where I think having a big company owning the OS probably helps them stay ahead, as that structure probably lets them work with hardware designers to get the capabilities in use (i.e. in new versions of DirectX) and available to software developers first. There's generally a lag in adoption for new features within Vulkan and then usage downstream in wine/proton to get compatibility parity with windows, then the games themselves being able to run feature/performance parity. It'd be interesting to see what cooperation would be needed to have the linux gaming stack equal at the point new features are released, and with the least amount of manual hacks or command line tweaking required for the users. As discussed a few weeks back, tough anti-cheat for linux seems like a paradox with the current methods.
mschuster91 | 21 hours ago
Microsoft doesn't give a fuck about private customers any more. They don't have money.
What has money though is enterprise/government sales, and MS got these customers tightly locked in. Compliance audits and tooling for insurances or legal stuff (SOX, GDPR, ...) are built against a full Microsoft stack of MS Server, Active Directory, Azure, Teams, Office 365 and Windows desktops.
You might be able to get away with replacing AD and GPO with Samba servers but even that is already a pain when the auditors come knocking. Everything else? There is no single FOSS based "standard offering" (i.e. a combination of everything needed to run an on-prem enterprise site, Office replacement, remote collaboration tooling), so every audit for such setups must be custom made and involves a lot of extra work.
A second leg is industrial control machines, medical devices and the likes. That's all stuff built by third party vendors and integrators. They need to continue on Windows because switching to an alternative OS would require redoing everything from scratch on the software and certification side. These customers buy the LTSC IoT stuff.
And that is why you see Microsoft pushing enshittification so hard on private customers... extract the last few cents you can from them. But the real money comes from the large customers.
porphyra | 23 hours ago
duskwuff | 23 hours ago
senfiaj | 17 hours ago
simoncion | 15 hours ago
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.
duskwuff | 13 hours ago
consp | 11 hours ago
anthk | 21 hours ago
rescbr | 17 hours ago
anthk | 10 hours ago
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.
zadikian | 12 hours ago
beAbU | 6 hours ago
https://arstechnica.com/gaming/2025/06/games-run-faster-on-s...
wing-_-nuts | 2 hours ago
Aerroon | 22 hours ago
voodooEntity | 21 hours ago
beAbU | 6 hours ago
Secondly, I do acknowlege your 40k reference.
pjmlp | 9 hours ago
WSL is already there for the folks that want to play with Linux.
alexrp | 22 hours ago
wing-_-nuts | 2 hours ago
_flux | 23 hours ago
Finally some embrace, extend, and extinguish love right back at Microsoft!
zerocrates | 23 hours ago
akdev1l | 23 hours ago
What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.
Such application could be rebuilt to work with an older glibc as the API is stable. The ABI is not which is why the application would need to be rebuilt.
glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed. Maintaining a stable ABI mostly helps proprietary software where the source is not available for recompilation. Naturally the gnu guys building glibc don’t care about that use case much.
I guess you didn’t mention glibc in your comment but I already typed this out
charcircuit | 22 hours ago
akdev1l | 22 hours ago
From a bit of research it looks like FreeBSD for example only provides a stable ABI within minor versions and I imagine if you build something for FreeBSD 14 it won’t work on 13.
Stable ABI literally only benefits software where the user doesn’t have the source. Any operating system which assumes you have the source will not prioritize it.
(Edit: actually thinking harder MacOS/iOS is actually much worse on binary compatibility, as for example Intel binaries will stop working entirely due to M-cpu transition - Apple just hits developers with a stick to rebuild their apps)
kelnos | 21 hours ago
> Stable ABI literally only benefits software where the user doesn’t have the source.
It also benefits people who don't want to have to do busywork every time the OS updates.
toast0 | 21 hours ago
At Yahoo, we'd build on 4.3-4.8, and run on 4.x - 8.x. At WhatsApp, I think I remember mostly building on 8.x and 9.x, for 8.x - 11.x. The only thing that I remember causing major problems was extending the bitmask for CPU pinning; there were a couple updates where old software + old kernel CPU pinning would work, and old software + new kernel CPU pinning failed; eventually upstream made that better as long as you don't run old software on a system with more cores than fit in the bitmask. I'm sure there were a few other issues, but I don't remember them ...
charcircuit | 21 hours ago
akdev1l | 20 hours ago
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)
littlecranky67 | 10 hours ago
wing-_-nuts | 2 hours ago
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.
throwaway2046 | 12 hours ago
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.
thescriptkiddie | 22 hours ago
kelnos | 22 hours ago
Apple may require rebuilds at some point for their Mac Store (or whatever they call it), but it's not required from a technical perspective.
The one exception here is CPU architecture changes, and even then, Apple has provided seamless emulation/translation layers that they keep around for quite a few years before dropping support.
charcircuit | 21 hours ago
https://developer.apple.com/support/xcode/
kelnos | 22 hours ago
Is this correct? I think you perhaps have it backward? If I compile something against the glibc on my system (Debian testing), it may fail to run on older Debian releases that have older glibc versions. But I don't see why an app built against glibc 2.12 wouldn't run on Debian testing. glibc actually does a good job of using symbol versioning, and IIRC they haven't removed any public functions, so I don't see why this wouldn't work.
More at issue would be the availability of other dependencies. If that old binary compiled against glibc 2.12 was also linked with, say, OpenSSL 0.9.7, I'd have to go out and build a copy of that myself, as Debian no longer provides it, and OpenSSL 3.x is not ABI-compatible.
> glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed.
If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux. And I wouldn't blame them.
akdev1l | 20 hours ago
If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work
>If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux.
Not really a show stopper, vendors just do what vendors do and bundle all their dependencies in. Similar to windows when you use anything outside of the win32 API.
The only problem with this approach is that glibc cannot have multiple versions running at once. We have “fixed” this with process namespaces and hence containers/flatpak where you can bundle everything including your own glibc.
Naturally the downside is that each app bundles their own libraries.
em-bee | 20 hours ago
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
seba_dos1 | 19 hours ago
In the context of games, that will likely be Steam Runtime.
em-bee | 18 hours ago
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.
seba_dos1 | 17 hours ago
akdev1l | 18 hours ago
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)
jdpage | 18 hours ago
SAI_Peregrinus | 4 hours ago
krastanov | 21 hours ago
em-bee | 19 hours ago
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.Levitating | 18 hours ago
cylemons | 8 hours ago
HerbManic | 22 hours ago
beAbU | 6 hours ago
bsimpson | 4 hours ago
For x86, that's Windows. For mobile/VR, it's Android.
Normal_gaussian | 23 hours ago
tombert | 23 hours ago
Jblx2 | 23 hours ago
ticulatedspline | 23 hours ago
Either way my comment is intended as more humorous than truly insightful or prophetic.
BadBadJellyBean | 22 hours ago
Jblx2 | 17 hours ago
orbital-decay | 23 hours ago
akdev1l | 23 hours ago
DOOM runs on any Linux system since forever because we had access to the source. You can build it for Linux 2.6 and it’ll probably still work today.
Sadly most games are proprietary
fluffybucktsnek | 22 hours ago
badsectoracula | 15 hours ago
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
Pannoniae | 8 hours ago
In the end I gave up and just used proton on the windows .exe. Unbelievable. :(
akdev1l | 4 hours ago
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.
LtWorf | 22 hours ago
fluffybucktsnek | 22 hours ago
LtWorf | 21 hours ago
Which means that a .exe without the exact version of wine won't run.
Plus of course there's the whole vulkan stuff. Older cards aren't well supported but it will rather crash than just run openGL normally where it would work fine.
orbital-decay | 21 hours ago
>What works fine today will completely fail next year.
Usually not on the timescale of a year. I have many new games that worked a year ago and none of these stopped working now. The worst breakage I had recently was some physics glitches in an old RPG (released in 2001) on Wine 11.0, and it was fixed in the next release.
fluffybucktsnek | 21 hours ago
seba_dos1 | 19 hours ago
It's effective enough for it to be practically a solved problem now.
orbital-decay | 22 hours ago
TheCycoONE | 21 hours ago
anthk | 21 hours ago
DeathArrow | 23 hours ago
cadamsdotcom | 23 hours ago
2OEH8eoCRo0 | 23 hours ago
inetknght | 23 hours ago
marssaxman | 22 hours ago
FpUser | 22 hours ago
kelnos | 22 hours ago
Also the Windows ABI is still more stable than the Linux ABI. Even if Linux (non-SteamDeck) gaming share went up to like 50% or more, it still would probably be less of a hassle to build for Windows only, the performance difference on Linux+Wine isn't enough to matter.
nialv7 | 21 hours ago
nutrientharvest | 19 hours ago
hrmtst93837 | 12 hours ago
adelmotsjr | 23 hours ago
brailsafe | 23 hours ago
eurg | 23 hours ago
DeathArrow | 23 hours ago
CRUDs do pay the bills.
zerr | 23 hours ago
irishcoffee | 23 hours ago
chistev | 22 hours ago
bombcar | 22 hours ago
anthk | 21 hours ago
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.
timacles | 18 hours ago
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
bombcar | 16 hours ago
CRUD developers know that they never, ever will, because business logic is insane.
JollySharp0 | 6 hours ago
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.
bombcar | 5 hours ago
JollySharp0 | 5 hours ago
phist_mcgee | 22 hours ago
Jog on.
nurettin | 22 hours ago
anthk | 22 hours ago
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.
whateveracct | 17 hours ago
zerr | 7 hours ago
-drews | 22 hours ago
Rick76 | 22 hours ago
He will talk about OS events, or any low level concept and it makes me feel like I don’t know anything, but he acts like I’m a genius if I talk about JavaScript Runtimes, browser engines, anything frontend.
It’s cool he teaches me new things, I teach him some
__natty__ | 21 hours ago
throwawaytea | 17 hours ago
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.
surajrmal | 5 hours ago
Pannoniae | 8 hours ago
guzfip | 5 hours ago
You don’t. Someone else smarter than you handled it already and you just need to integrate their solution.
dgunay | 23 hours ago
dmitrygr | 22 hours ago
Teknoman117 | 22 hours ago
If I were more money motivated I’d probably be building CRUD apps too. I just like weird puzzles XD.
zem | 22 hours ago
amoss | 11 hours ago
zem | 10 hours ago
amoss | 6 hours ago
johnnyanmac | 22 hours ago
pier25 | 22 hours ago
dole | 21 hours ago
kalinkochnev | 20 hours ago
IIsi50MHz | 26 minutes ago
wishfish | 22 hours ago
genodethrowaway | 16 hours ago
rationalist | 16 hours ago
Looking at your comments however, while probably not AI, they're still not helpful.
crustaceansoup | 14 hours ago
wishfish | 5 hours ago
First time I've been accused of AI.
komali2 | 16 hours ago
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 -
wishfish | 5 hours ago
guzfip | 5 hours ago
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.
samus | 2 hours ago
crtified | 21 hours ago
torginus | 19 hours ago
Deebster | 3 hours ago
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.
JollySharp0 | 6 hours ago
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.
Tade0 | 5 hours ago
hu3 | 23 hours ago
> Resident Evil 2 jumped from 26 FPS to 77 FPS
> Call of Juarez went from 99.8 FPS to 224.1 FPS
> Tiny Tina's Wonderlands saw gains from 130 FPS to 360 FPS
Amazing. I don't understand the low level details on how such a massive speed gain was ripe for the picking but I welcome!
I guess thanks Valve for pouring money into Proton.
bmenrigh | 23 hours ago
That said, Wine+ntsync is still a win, just not a 8x improvement like the Dirt 3 benchmark suggests.
(And it case it's not clear, ntsync is https://docs.kernel.org/userspace-api/ntsync.html, which is a driver for Linux that offers syncronization primitives (mutex, semaphore, events) that more closely match the semantics of the Windows primitives. It's easier to do a direct implementation in Wine to support code compiled for Windows that expects to be talking to an NT kernel.)
creesch | 22 hours ago
The article actually goes into that in quite a bit of detail about that.
bmenrigh | 22 hours ago
torginus | 19 hours ago
ElectricalUnion | 18 hours ago
qalmakka | 11 hours ago
sirjaz | 5 hours ago
qalmakka | 5 hours ago
Levitating | 18 hours ago
iknowstuff | 23 hours ago
ToucanLoucan | 21 hours ago
jeppester | 21 hours ago
gpderetta | 21 hours ago
ToucanLoucan | 21 hours ago
I absolutely love my Ally running SteamOS. Incredible work by... everyone involved, really.
rounce | 20 hours ago
Dystakruul | 19 hours ago
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
psyonity | 11 hours ago
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.
badsectoracula | 16 hours ago
[0] https://github.com/Open-Wine-Components/umu-launcher
diath | 11 hours ago
> 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.
hu3 | 10 hours ago
It means these games were already running well in Linux and even better now.
sumtechguy | 6 hours ago
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.
tombert | 23 hours ago
I don't know for sure, but I suspect that a lot of the work for Wine is boring and thankless. Digging through and trying to get exact parity with both the documented and undocumented behavior of Windows for the past 30 years doesn't sound fun, but it's finding every little weird edge case that makes Wine a viable product.
The fact that Wine runs a lot of games better than Windows now (especially older games) shows a very strong attention to detail and a high tolerance for pain. I commend them for it.
hxorr | 22 hours ago
pdpi | 22 hours ago
MisterTea | 21 hours ago
Induane | 20 hours ago
badsectoracula | 16 hours ago
[0] https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...
DaSHacka | 15 hours ago
rhdunn | 22 hours ago
dingdingdang | 18 hours ago
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.
RunningDroid | 18 hours ago
I believe that's what Winelib is for: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-G...
dingdingdang | 3 hours ago
tosti | an hour ago
The rest should be a matter of include and linker paths, but that's all I can recall right now.
refulgentis | 22 hours ago
anal_reactor | 22 hours ago
jhoechtl | 22 hours ago
m463 | 22 hours ago
does microsoft still sell office?
ThrowawayB7 | 21 hours ago
- https://www.microsoft.com/en-us/microsoft-365/p/office-home-...
- https://www.microsoft.com/en-us/microsoft-365/p/office-home-...
tom_alexander | 21 hours ago
dhosek | 21 hours ago
1bpp | 19 hours ago
Asmod4n | 20 hours ago
tracker1 | an hour ago
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.
pkaye | 21 hours ago
novos | 22 hours ago
mrec | 21 hours ago
RachelF | 21 hours ago
It is a pity that the apps most business people use everyday, like Word and Excel and Outlook don't work in it (Excel 2010 is the last version that has Platinum status). It is interesting that these are harder to get working than games.
coldpie | 21 hours ago
Games are mostly just doing their own thing, only interacting with the system for input & output. MS Office is using every single corner of Windows: every feature in the XML libraries, tons of .NET type stuff, all the OLE and COM and typelib and compound storage features, tons of Explorer integrations, auto-updating stuff via Windows patching mechanisms... there's almost no corner of the Windows OS that MS Office doesn't use.
joe_mamba | 21 hours ago
Asmod4n | 21 hours ago
joe_mamba | 20 hours ago
ndriscoll | 19 hours ago
tombert | 17 hours ago
I had to use PCem to get support for that stuff.
sersi | 14 hours ago
tryauuum | 12 hours ago
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
Asmod4n | 8 hours ago
joe_mamba | 5 hours ago
Asmod4n | 5 hours ago
tombert | 20 hours ago
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".
vbezhenar | 20 hours ago
They should be trivial to port then, no?
Rohansi | 20 hours ago
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.
MindSpunk | 19 hours ago
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.
simonask | 18 hours ago
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.
p1necone | 20 hours ago
greiskul | 19 hours ago
tosti | 3 hours ago
There does exist flatpak, everything that would benefit from a stable ABI could use that.
codebje | 19 hours ago
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.
alpaca128 | 16 hours ago
The problem with DRM is the DRM.
RajT88 | 20 hours ago
nicoburns | 19 hours ago
usrusr | 19 hours ago
bombcar | 18 hours ago
fock | 11 hours ago
rowyourboat | 11 hours ago
dkersten | 10 hours ago
9wzYQbTYsAIc | 6 hours ago
JPLeRouzic | 11 hours ago
Like obsolete Longene project?
https://en.wikipedia.org/wiki/Longene
da_chicken | 16 hours ago
Discordian93 | 16 hours ago
johnebgd | 13 hours ago
Grisu_FTP | 11 hours ago
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)
ifwinterco | 10 hours ago
jitl | 6 hours ago
exceptione | 10 hours ago
tsimionescu | 2 hours ago
lp0_on_fire | 5 hours ago
And it's horrible.
Quothling | 12 hours ago
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.)
mietek | 3 hours ago
You're probably breaking EU law by building this nightmare.
https://artificialintelligenceact.eu/article/86/
bigfudge | 3 hours ago
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?
badpun | 5 hours ago
coldpie | 5 hours ago
philipwhiuk | 20 hours ago
codebje | 19 hours ago
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.
YokoZar | 11 hours ago
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.
Grisu_FTP | 11 hours ago
jitl | 6 hours ago
josh_p | 17 hours ago
saidnooneever | 9 hours ago
computomatic | 21 hours ago
ACS_Solver | 20 hours ago
owaislone | 20 hours ago
amatecha | 20 hours ago
sdenton4 | 14 hours ago
HWR_14 | 13 hours ago
worthless-trash | 11 hours ago
colejohnson66 | 5 hours ago
HWR_14 | 5 hours ago
ZiiS | 11 hours ago
cultofmetatron | 12 hours ago
Arwill | 11 hours ago
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.
cultofmetatron | 9 hours ago
johanvts | 5 hours ago
Hikikomori | 8 hours ago
anakaine | 13 hours ago
BatteryMountain | 11 hours ago
hochmartinez | 10 hours ago
moring | 10 hours ago
red-iron-pine | 6 hours ago
colejohnson66 | 5 hours ago
moring | 2 hours ago
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.
greenavocado | 5 hours ago
moralestapia | 3 hours ago
moring | 2 hours ago
moralestapia | 24 minutes ago
lebed2045 | 4 hours ago
OccamsMirror | 10 hours ago
exitb | 10 hours ago
rickdeckard | 10 hours ago
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...
colejohnson66 | 5 hours ago
https://taxpolicycenter.org/taxvox/who-gets-tax-benefit-thos...
BobaFloutist | 4 hours ago
colejohnson66 | 2 hours ago
tstenner | 7 hours ago
BatteryMountain | 5 hours ago
GreenVulpine | 4 hours ago
stavros | 3 hours ago
lo_zamoyski | 4 hours ago
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.
InitialLastName | 4 hours ago
mietek | 3 hours ago
patmorgan23 | 3 hours ago
https://news.ycombinator.com/item?id=34061110
ErroneousBosh | 11 hours ago
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!
duttish | an hour ago
Space Marine 2 was the latest one for me, but Steam is great at refunds if you do it quickly enough.
aranelsurion | 20 hours ago
spoiler | 19 hours ago
Also, I assume some Windows version jumps didn't make things easy for Wine either lol
xattt | 17 hours ago
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?
Fnoord | 13 hours ago
aaronbrethorst | 13 hours ago
zadikian | 12 hours ago
pxc | 5 hours ago
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.
ryukoposting | 16 hours ago
brnt | 12 hours ago
ecshafer | 17 hours ago
figmert | 14 hours ago
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.
donatj | 12 hours ago
whalesalad | 4 hours ago
samus | 2 hours ago
tracker1 | an hour ago
ConceptJunkie | 41 minutes ago
If a program didn't work on a newer version of Windows, there's a good chance it was doing something unsupported.
samus | 29 minutes ago
Perepiska | 21 hours ago
dwroberts | 19 hours ago
It's like the most trivial thing to change
dhosek | 21 hours ago
⸻
1. A frequent debate about the time was whether this was a wise thing to do as it reduced the motivation for developers to create OS/2-native versions of applications. The slow death of OS/2 can be interpreted as both support for those who felt that Windows-under-OS/2 was a bad idea and those who felt that OS/2 was doomed from the start in the face of the Windows monopoly.
2. Largely because I’m not a gamer—when I’ve looked at what it takes, both in terms of hardware and in learning how to do stuff in games, I’ve decided that I’m happy staying that way.
alilikestech | 20 hours ago
orbital-decay | 18 hours ago
stevefan1999 | 17 hours ago
Kuraj | 20 hours ago
sneak | 18 hours ago
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.
jsLavaGoat | 18 hours ago
sneak | 17 hours ago
MSFT_Edging | 7 hours ago
stevefan1999 | 17 hours ago
pyuser583 | 16 hours ago
It’s gotten good and reliable.
Commendations to contributors!
JKCalhoun | 15 hours ago
Man, Wine just worked and I confess I copped out and just delivered MacOS and Windows targets.
brightball | 23 hours ago
watashiato | 23 hours ago
akdev1l | 23 hours ago
Not for anyone using a kernel without these patches. Which would be most people.
foresto | 23 hours ago
akdev1l | 23 hours ago
It looks there was a copr for a custom kernel-fsync and projects like Bazzite or Nobara are adding patches.
From my understanding the fsync patches were never upstreamed.
foresto | 22 hours ago
The point being that these massive speed gains will probably not be seen by most people as you suggest, because most Linux gamers already have access to either esync or fsync.
akdev1l | 22 hours ago
foresto | 22 hours ago
The Proton build is Valve's build. It supports both fsync and esync, the latter of which does not require a kernel patch. If you're gaming on Linux with Steam, you're probably already using it.
https://github.com/ValveSoftware/Proton/?tab=readme-ov-file#...
akdev1l | 20 hours ago
kelnos | 22 hours ago
Sure, gaming-focused distros, or distros like Arch or Gentoo might (optionally or otherwise), but mainstream? Probably not.
Of course, esync doesn't require kernel patches, so I imagine that was more broadly out there. But it sounds like fsync got you performance pretty close to what ntsync can do, but esync was quite a bit behind both? With vanilla being quite a bit behind esync?
(Also, jeez, fsync, what a terrible name. fsync is a syscall that has to do with filesystem data. So confusing.)
nialv7 | 21 hours ago
genthree | 21 hours ago
akdev1l | 18 hours ago
Fedora looks like it carries a whooping 2 patches on top of upstream
foresto | 21 hours ago
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. :)
IshKebab | 20 hours ago
jabl | 11 hours ago
damentz | 17 hours ago
tremon | an hour ago
kvemkon | 18 hours ago
Is it worth to compare Wayland vs X11?
Night_Thastus | 23 hours ago
Now if we can just get some decent Nvidia drivers......
k33n | 23 hours ago
Duralias | 21 hours ago
Night_Thastus | 20 hours ago
rounce | 18 hours ago
braiamp | 9 hours ago
drnick1 | 4 hours ago
DeathArrow | 23 hours ago
hungryhobbit | 22 hours ago
dmitrygr | 22 hours ago
xuhu | 5 hours ago
SeriousM | 23 hours ago
metalliqaz | 14 hours ago
SeriousM | 13 hours ago
LetsGetTechnicl | 23 hours ago
jordand | 22 hours ago
bombcar | 18 hours ago
senfiaj | 17 hours ago
lifis | 22 hours ago
It seems that neither esync or fsync do this though - why?
Claude thinks that "nobody was motivated enough to write and debug the complex shared-memory waiter-list logic when simpler (if less correct) approaches worked for 95% of games, and when correctness finally mattered enough, the kernel was the more natural place to put it". Is that true?
evmar | 22 hours ago
topspin | 21 hours ago
It is not. Perhaps this should be possible, but Linux doesn't provide userspace facilities that would be necessary to do this entirely in userspace.
This is not merely an API shim that allows Windows binary object to dynamically link and run. It’s an effort to recreate the behavior of NT kernel synchronization and waiting semantics. To do this, Linux kernel synchronization primitives and scheduler API must be used. You can read the code[1] and observe that this is a compatibility adapter that relies heavily on Linux kernel primitives and their coordination with the kernel scheduler. No approach using purely user space synchronization primitives can do this both efficiently and accurately.
[1] https://github.com/torvalds/linux/blob/master/drivers/misc/n...
lifis | 20 hours ago
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.
topspin | 18 hours ago
[1] https://lkml.org/lkml/2019/7/30/1399 [2] https://docs.kernel.org/userspace-api/ntsync.html
garaetjjte | 18 hours ago
https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5a...
dangoodmanUT | 22 hours ago
And then it never was more than half…
sph | 22 hours ago
philipwhiuk | 20 hours ago
So most of it.
ptx | 22 hours ago
trentnelson | 21 hours ago
There’s never been a POSIX equivalent to this. It requires sophisticated kernel support and the exact same parity can’t be achieved in user space alone.
modeless | 20 hours ago
braiamp | 9 hours ago
gpderetta | 20 hours ago
dwattttt | 13 hours ago
There was also something about needing to back out if any of the reads fails to acquire, which also sounds nasty.
gpderetta | 11 hours ago
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.
evmar | 22 hours ago
vintagedave | 21 hours ago
FYI the link to the Rosetta branch at the end 404s. Maybe change the point to the main repo?
evmar | 20 hours ago
mschuster91 | 21 hours ago
Does that also apply to macOS? Even on Intel machines, Apple dropped 32-bit support many many years ago and IIRC it took ugly workarounds that weren't ever part of upstream WINE but of Crossover.
hatmanstack | 21 hours ago
Blackthorn | 21 hours ago
oompydoompy74 | 21 hours ago
Twisol | 20 hours ago
mft_ | 20 hours ago
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.
SV_BubbleTime | 15 hours ago
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.
Levitating | 7 hours ago
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/
IshKebab | 10 hours ago
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).
mft_ | 6 hours ago
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.
scott01 | 9 hours ago
basemi | 9 hours ago
[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)
mft_ | 5 hours ago
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.
childintime | 2 hours ago
ReactOS is always almost there.. except it doesn't quite get there; same goes for Wine, as they have a lot in common?
mifydev | 19 hours ago
gigel82 | 19 hours ago
sourcegrift | 17 hours ago
igravious | 17 hours ago
the gains would trickle up, no?
igravious | 17 hours ago
https://www.codeweavers.com/crossover/download
SeriousM | 13 hours ago
SXX | 12 hours ago
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.
igravious | 9 hours ago
CodeWeavers : Wine :: IBM/RedHat : Fedora
tuananh | 12 hours ago
pojzon | 11 hours ago
Can we finally ditch windows ?
Nican | 11 hours ago
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.
BatteryMountain | 11 hours ago
hnarn | 11 hours ago
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.
BatteryMountain | 10 hours ago
SomeUserName432 | 10 hours ago
BatteryMountain | 10 hours ago
jojomodding | 3 hours ago
asimovDev | 8 hours ago
samus | 2 hours ago
thn-gap | 2 hours ago
cpx86 | 2 hours ago
BatteryMountain | 2 hours ago
cpx86 | an hour ago
Prunkton | 11 hours ago
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/
dmos62 | 11 hours ago
angelfangs | 9 hours ago
alfanick | 7 hours ago
eb0la | 7 hours ago
beAbU | 6 hours ago
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!
alfanick | 4 hours ago
neonstatic | 7 hours ago
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
AdamConwayIE | 6 hours ago
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.
neonstatic | 3 hours ago
razkaplan | 5 hours ago
noisy_boy | 4 hours ago