I don't know for sure, but I suspect that a lot of the work for Wine is boring and thankless. Digging through and trying to get exact parity with both the documented and undocumented behavior of Windows for the past 30 years doesn't sound fun, but it's finding every little weird edge case that makes Wine a viable product.
The fact that Wine runs a lot of games better than Windows now (especially older games) shows a very strong attention to detail and a high tolerance for pain. I commend them for it.
Also, I assume some Windows version jumps didn't make things easy for Wine either lol
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?
It is a pity that the apps most business people use everyday, like Word and Excel and Outlook don't work in it (Excel 2010 is the last version that has Platinum status). It is interesting that these are harder to get working than games.
Games are mostly just doing their own thing, only interacting with the system for input & output. MS Office is using every single corner of Windows: every feature in the XML libraries, tons of .NET type stuff, all the OLE and COM and typelib and compound storage features, tons of Explorer integrations, auto-updating stuff via Windows patching mechanisms... there's almost no corner of the Windows OS that MS Office doesn't use.
They should be trivial to port then, no?
Despite all this the Unity engine has spotty Linux support. Some games run better under Wine vs. Unity's native Linux builds. It's Vulkan renderer has had a memory leak for a while now. Input has randomly decided to double keypresses on some distros.
Platform bugs, build issues, distro differences, implicitly relying on behavior of Windows. It's not just "use Linux API", there's a lot of effort to ship properly. Lots of effort for a tiny user base. There's more users now, but proton is probably a better target than native Linux for games.
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.
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.
The problem with DRM is the DRM.
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".
I had to use PCem to get support for that stuff.
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.
Is there any way I can use the Wine project to facilitate this compiling and running straight under x11/linux environment as a integrated project that doesn't require the end user to fiddle with Wine? I don't mind bundling shared code as needed. Help appreciated, I tried hard and failed at this endeavour priorly.
I believe that's what Winelib is for: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-G...
[0] https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...
Man, Wine just worked and I confess I copped out and just delivered MacOS and Windows targets.
⸻
1. A frequent debate about the time was whether this was a wise thing to do as it reduced the motivation for developers to create OS/2-native versions of applications. The slow death of OS/2 can be interpreted as both support for those who felt that Windows-under-OS/2 was a bad idea and those who felt that OS/2 was doomed from the start in the face of the Windows monopoly.
2. Largely because I’m not a gamer—when I’ve looked at what it takes, both in terms of hardware and in learning how to do stuff in games, I’ve decided that I’m happy staying that way.
It’s gotten good and reliable.
Commendations to contributors!
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.
does microsoft still sell office?
- https://www.microsoft.com/en-us/microsoft-365/p/office-home-...
- https://www.microsoft.com/en-us/microsoft-365/p/office-home-...
It's like the most trivial thing to change
> Resident Evil 2 jumped from 26 FPS to 77 FPS
> Call of Juarez went from 99.8 FPS to 224.1 FPS
> Tiny Tina's Wonderlands saw gains from 130 FPS to 360 FPS
Amazing. I don't understand the low level details on how such a massive speed gain was ripe for the picking but I welcome!
I guess thanks Valve for pouring money into Proton.
That said, Wine+ntsync is still a win, just not a 8x improvement like the Dirt 3 benchmark suggests.
(And it case it's not clear, ntsync is https://docs.kernel.org/userspace-api/ntsync.html, which is a driver for Linux that offers syncronization primitives (mutex, semaphore, events) that more closely match the semantics of the Windows primitives. It's easier to do a direct implementation in Wine to support code compiled for Windows that expects to be talking to an NT kernel.)
The article actually goes into that in quite a bit of detail about that.
I've heard it's pretty good for fixing video playback/rendering (e.g. cutscene) issues if both the stable and the experimental branch of Proton can't make it work.
I absolutely love my Ally running SteamOS. Incredible work by... everyone involved, really.
Not for anyone using a kernel without these patches. Which would be most people.
Sure, gaming-focused distros, or distros like Arch or Gentoo might (optionally or otherwise), but mainstream? Probably not.
Of course, esync doesn't require kernel patches, so I imagine that was more broadly out there. But it sounds like fsync got you performance pretty close to what ntsync can do, but esync was quite a bit behind both? With vanilla being quite a bit behind esync?
(Also, jeez, fsync, what a terrible name. fsync is a syscall that has to do with filesystem data. So confusing.)
It's best not to assume with these things. With my stock Debian Stable kernel, Proton says this:
fsync: up and running.
And when I disable fsync, it says this:
esync: up and running.
> But it sounds like fsync got you performance pretty close to what ntsync can do, but esync was quite a bit behind both?
No, esync and fsync trade blows in performance. Here are some measurements taken by Kron4ek, who maintains somewhat widely used Wine/Proton builds:
https://web.archive.org/web/20250315200334/https://flightles...
https://web.archive.org/web/20250315200424/https://flightles...
https://web.archive.org/web/20250315200419/https://flightles...
> With vanilla being quite a bit behind esync?
Yes, vanilla Wine has historically fallen behind all of them, of course.
> Also, jeez, fsync, what a terrible name. fsync is a syscall that has to do with filesystem data. So confusing.
We can agree on this. :)
Fedora looks like it carries a whooping 2 patches on top of upstream
It looks there was a copr for a custom kernel-fsync and projects like Bazzite or Nobara are adding patches.
From my understanding the fsync patches were never upstreamed.
The point being that these massive speed gains will probably not be seen by most people as you suggest, because most Linux gamers already have access to either esync or fsync.
The Proton build is Valve's build. It supports both fsync and esync, the latter of which does not require a kernel patch. If you're gaming on Linux with Steam, you're probably already using it.
https://github.com/ValveSoftware/Proton/?tab=readme-ov-file#...
Is it worth to compare Wayland vs X11?
As a fellow CRUD writer you're kinda seconding the OP's point here...
Personally I say oh well, some people are smarter and/or harder working than me. Now watch this drive -
Looking at your comments however, while probably not AI, they're still not helpful.
He will talk about OS events, or any low level concept and it makes me feel like I don’t know anything, but he acts like I’m a genius if I talk about JavaScript Runtimes, browser engines, anything frontend.
It’s cool he teaches me new things, I teach him some
Most people know that there is a big difference between experience in something pretty easy vs mastery of something very difficult.
A rocket scientist acknowledges a concrete guy knows way more than he does about concrete, but also knows that doesn't make him a genius because it's easy enough to learn just being around it. Plus, the rocket scientist also knows that since he knows so little about concrete, he wouldn't even be able to judge if the guy is really a concrete genius or just saying things a real pro would label wrong.
Your example isn't that crazy, but still, you should realize your friend is just being nice.
Jog on.
On bit shifts, pick any Forth programmer and shaders will be almost like a toy for them. They are used to implement double numbers (and maybe floats) themselves by hand by just reusing the only integer numbers they have and writting custom commands to output these pairs of integer as double numbers. They can probably implement multithreading processing by hand in Forth and also know the IEEE standards for floats better than C programmers over 20 years.
GUI interfaces for the enterprise came from Dante's hell themselves. I hate them, they are like the Madhouse from that Asterix movie making satire of the European bureucracy of the day. The often are oddly designed and they are not documented at all, you must guess the meaning by chance of with a senior tutoring you.
The same with anything corporate from Microsoft with AD roles/group policies and the like. Or anything coming from IBM.
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
CRUD developers know that they never, ever will, because business logic is insane.
If I were more money motivated I’d probably be building CRUD apps too. I just like weird puzzles XD.
CRUDs do pay the bills.
So most of it.
Bleeding edge gaming and multiplayer anti-cheat is one area where I think having a big company owning the OS probably helps them stay ahead, as that structure probably lets them work with hardware designers to get the capabilities in use (i.e. in new versions of DirectX) and available to software developers first. There's generally a lag in adoption for new features within Vulkan and then usage downstream in wine/proton to get compatibility parity with windows, then the games themselves being able to run feature/performance parity. It'd be interesting to see what cooperation would be needed to have the linux gaming stack equal at the point new features are released, and with the least amount of manual hacks or command line tweaking required for the users. As discussed a few weeks back, tough anti-cheat for linux seems like a paradox with the current methods.
Microsoft doesn't give a fuck about private customers any more. They don't have money.
What has money though is enterprise/government sales, and MS got these customers tightly locked in. Compliance audits and tooling for insurances or legal stuff (SOX, GDPR, ...) are built against a full Microsoft stack of MS Server, Active Directory, Azure, Teams, Office 365 and Windows desktops.
You might be able to get away with replacing AD and GPO with Samba servers but even that is already a pain when the auditors come knocking. Everything else? There is no single FOSS based "standard offering" (i.e. a combination of everything needed to run an on-prem enterprise site, Office replacement, remote collaboration tooling), so every audit for such setups must be custom made and involves a lot of extra work.
A second leg is industrial control machines, medical devices and the likes. That's all stuff built by third party vendors and integrators. They need to continue on Windows because switching to an alternative OS would require redoing everything from scratch on the software and certification side. These customers buy the LTSC IoT stuff.
And that is why you see Microsoft pushing enshittification so hard on private customers... extract the last few cents you can from them. But the real money comes from the large customers.
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.
Finally some embrace, extend, and extinguish love right back at Microsoft!
What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.
Such application could be rebuilt to work with an older glibc as the API is stable. The ABI is not which is why the application would need to be rebuilt.
glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed. Maintaining a stable ABI mostly helps proprietary software where the source is not available for recompilation. Naturally the gnu guys building glibc don’t care about that use case much.
I guess you didn’t mention glibc in your comment but I already typed this out
Is this correct? I think you perhaps have it backward? If I compile something against the glibc on my system (Debian testing), it may fail to run on older Debian releases that have older glibc versions. But I don't see why an app built against glibc 2.12 wouldn't run on Debian testing. glibc actually does a good job of using symbol versioning, and IIRC they haven't removed any public functions, so I don't see why this wouldn't work.
More at issue would be the availability of other dependencies. If that old binary compiled against glibc 2.12 was also linked with, say, OpenSSL 0.9.7, I'd have to go out and build a copy of that myself, as Debian no longer provides it, and OpenSSL 3.x is not ABI-compatible.
> glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed.
If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux. And I wouldn't blame them.
If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work
>If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux.
Not really a show stopper, vendors just do what vendors do and bundle all their dependencies in. Similar to windows when you use anything outside of the win32 API.
The only problem with this approach is that glibc cannot have multiple versions running at once. We have “fixed” this with process namespaces and hence containers/flatpak where you can bundle everything including your own glibc.
Naturally the downside is that each app bundles their own libraries.
that's not correct. libraries have versions for a reason. the only thing preventing the installation of multiple glibc versions is the package manager or the package versioning.
this makes building against an older version of glibc non-trivial, because there isn't a ready made package that you can just install. the workarounds take effort:
https://stackoverflow.com/questions/2856438/how-can-i-link-t...
the problem for companies developing on linux is that it is not trivial
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)
In the context of games, that will likely be Steam Runtime.
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.
for example here is a 20 year old binary of the game mirrormagic that runs just fine on my modern fedora machine:
~/Downloads/mirrormagic-2.0.2> ldd mirrormagic
linux-gate.so.1 (0xf7f38000)
libX11.so.6 => /lib/libX11.so.6 (0xf7db5000)
libm.so.6 => /lib/libm.so.6 (0xf7cd0000)
libc.so.6 => /lib/libc.so.6 (0xf7ad5000)
libxcb.so.1 => /lib/libxcb.so.1 (0xf7aa9000)
/lib/ld-linux.so.2 (0xf7f3b000)
libXau.so.6 => /lib/libXau.so.6 (0xf7aa4000)
~/Downloads/mirrormagic-2.0.2> ls -la mirrormagic
-rwxr-xr-x. 1 em-bee em-bee 203633 Jun 7 2003 mirrormagic
From a bit of research it looks like FreeBSD for example only provides a stable ABI within minor versions and I imagine if you build something for FreeBSD 14 it won’t work on 13.
Stable ABI literally only benefits software where the user doesn’t have the source. Any operating system which assumes you have the source will not prioritize it.
(Edit: actually thinking harder MacOS/iOS is actually much worse on binary compatibility, as for example Intel binaries will stop working entirely due to M-cpu transition - Apple just hits developers with a stick to rebuild their apps)
> Stable ABI literally only benefits software where the user doesn’t have the source.
It also benefits people who don't want to have to do busywork every time the OS updates.
At Yahoo, we'd build on 4.3-4.8, and run on 4.x - 8.x. At WhatsApp, I think I remember mostly building on 8.x and 9.x, for 8.x - 11.x. The only thing that I remember causing major problems was extending the bitmask for CPU pinning; there were a couple updates where old software + old kernel CPU pinning would work, and old software + new kernel CPU pinning failed; eventually upstream made that better as long as you don't run old software on a system with more cores than fit in the bitmask. I'm sure there were a few other issues, but I don't remember them ...
By that point they already hit the developers enough to get them to port to aarch64
(arguably though this could be a special case because it is due to architectural transition)
Apple may require rebuilds at some point for their Mac Store (or whatever they call it), but it's not required from a technical perspective.
The one exception here is CPU architecture changes, and even then, Apple has provided seamless emulation/translation layers that they keep around for quite a few years before dropping support.
Also the Windows ABI is still more stable than the Linux ABI. Even if Linux (non-SteamDeck) gaming share went up to like 50% or more, it still would probably be less of a hassle to build for Windows only, the performance difference on Linux+Wine isn't enough to matter.
DOOM runs on any Linux system since forever because we had access to the source. You can build it for Linux 2.6 and it’ll probably still work today.
Sadly most games are proprietary
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
Which means that a .exe without the exact version of wine won't run.
Plus of course there's the whole vulkan stuff. Older cards aren't well supported but it will rather crash than just run openGL normally where it would work fine.
>What works fine today will completely fail next year.
Usually not on the timescale of a year. I have many new games that worked a year ago and none of these stopped working now. The worst breakage I had recently was some physics glitches in an old RPG (released in 2001) on Wine 11.0, and it was fixed in the next release.
It's effective enough for it to be practically a solved problem now.
Either way my comment is intended as more humorous than truly insightful or prophetic.
OS/2 may have been a better Windows than Windows during the Warp days 30-ish years ago. It was also a very competent operating system in its own right.
We all know the story:
It never had a broad base of native applications. It could have happened, but it did not happen. Like, back then when Usenet was the primary way of conducting written online discourse, the best newsreader I had on OS/2 was a Windows program; the ones that ran natively on OS/2 weren't even close.
And OS/2 never had support from a popular company. There were times at OS/2's peak (such as it was) when it was essentially impossible to buy a new computer with OS/2 pre-installed and working correctly even from IBM.
Linux, though? Over those same 30-ish years, a huge amount of native applications have been written. Tons of day-to-day stuff can be done very well in Linux without even a hint of Wine and that's been reality for quite a long time now.
The missing piece, if there is one, is gaming. It'd be great to have more native games and fewer abstraction layers. But systems like Valve's popular Steam Deck and upcoming Steam Machine are positive aspects that OS/2 never had an equivalent to. And since Steam is very nearly ubiquitous, companies that sell computer game software do pay attention to what Valve is doing in this space.
(And frankly, when a game runs great in some Steam/Wine/Proton/Vulkan shapeshifting slime mold abstraction stack, I really do not care that it isn't running natively. I push the button and receive candy.)
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?
https://lore.kernel.org/lkml/f4cc1a38-1441-62f8-47e4-0c67f5a...
It is not. Perhaps this should be possible, but Linux doesn't provide userspace facilities that would be necessary to do this entirely in userspace.
This is not merely an API shim that allows Windows binary object to dynamically link and run. It’s an effort to recreate the behavior of NT kernel synchronization and waiting semantics. To do this, Linux kernel synchronization primitives and scheduler API must be used. You can read the code[1] and observe that this is a compatibility adapter that relies heavily on Linux kernel primitives and their coordination with the kernel scheduler. No approach using purely user space synchronization primitives can do this both efficiently and accurately.
[1] https://github.com/torvalds/linux/blob/master/drivers/misc/n...
That same code should be portable to userspace by: - Allocating everything into shared memory, where the shared memory fd replaces the ntsync device fd
- Using an index into a global table of object pointers instead of object fds
- Using futex-based mutexes instead of kernel spinlocks
- Using a futex-based parking/unparking system like parking_lot does
Obviously this breaks if the shared memory is corrupted or if you SIGKILL any process while it's touching it, but for Wine getting that seems acceptable. A kernel driver is clearly better though for this reason.
[1] https://lkml.org/lkml/2019/7/30/1399 [2] https://docs.kernel.org/userspace-api/ntsync.html
FYI the link to the Rosetta branch at the end 404s. Maybe change the point to the main repo?
https://github.com/Alien4042x/Wine-NTsync-Userspace-macOS-ba...
I mean, I know Mac has had some great games (eg. I spent so much time on school Macs playing that Bolo tank game) ... but they have probably <1% of the number of games Windows has. I'd expect a simiilar percentage of devs to be interested in Mace (or whatever you call Mac Wine).
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.
There’s never been a POSIX equivalent to this. It requires sophisticated kernel support and the exact same parity can’t be achieved in user space alone.
Now if we can just get some decent Nvidia drivers......
And then it never was more than half…
the gains would trickle up, no?
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.