felineflockWine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
https://www.xda-developers.com/wine-11-rewrites-linux-runs-windows-games-speed-gains/
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.
ReactOS also deserves an honorary mention. A lot of knowledge from that project feeds into Wine.
And vice-versa. It's pretty interesting that the two projects haven't kind of merged despite all the collaboration.
Wine has a lot of tests that are run across platforms to check conformance -- https://test.winehq.org/data/. These are a large part of why it has good compatibility.
With this exact point in mind: I've recently written a pretty straight forward win32 c implementation of a utility with some context dependent window interactions and a tray icon to help monitor and facility reload of config file.
Is there any way I can use the Wine project to facilitate this compiling and running straight under x11/linux environment as a integrated project that doesn't require the end user to fiddle with Wine? I don't mind bundling shared code as needed. Help appreciated, I tried hard and failed at this endeavour priorly.
It is a superb project, and a hard thing to do.
It is a pity that the apps most business people use everyday, like Word and Excel and Outlook don't work in it (Excel 2010 is the last version that has Platinum status). It is interesting that these are harder to get working than games.
> It is interesting that these are harder to get working than games.
Games are mostly just doing their own thing, only interacting with the system for input & output. MS Office is using every single corner of Windows: every feature in the XML libraries, tons of .NET type stuff, all the OLE and COM and typelib and compound storage features, tons of Explorer integrations, auto-updating stuff via Windows patching mechanisms... there's almost no corner of the Windows OS that MS Office doesn't use.
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.
> Games are mostly just doing their own thing, only interacting with the system for input & output.
They should be trivial to port then, no?
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.
Yeah but Windows is a more stable api to develop against than Linux (at least when it comes to stuff that games need to do) - it doesn't feel "pure", but pragmatically it's much better as a game developer to just make sure the Windows version works with proton than it is to develop a native Linux version that's liable to break the second you stop maintaining it.
As someone once said it best, Win32 is the only stable ABI on Linux: https://blog.hiler.eu/win32-the-only-stable-abi/
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.
I don't know that they are. It's just there's more incentive to port stuff that has no direct alternative.
Steam and CodeWeavers contribute a lot of code to the Wine project, because it underpins their business models of supporting Windows games on non-Windows platforms.
Between them they make up the vast bulk of what actually gets attention and improvement in Wine, and neither one has any interest in supporting non-game applications.
I 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.
Windows itself is a bunch of hacks, too, so if you think Wine is the same, then it surely looks like a very accurate emulation.
You seem to have missed this part of the comment you replied to:
> This was many years ago and I freely admit today that I was wrong.
Personally I stopped using Windows for gaming because it literally doesn't work anymore. I installed Windows 11 on my gaming VM and DLSS and FSR were just completely broken, didn't work at all. Couldn't figure it out. Switched to Linux (Bazzite for now) and I have no regrets; the only games that don't work are the dangerous time-wasters (live service games with invasive anti-cheat) that I have less and less time for as I age.
I remember managing to play Crysis under Linux with Wine and I was SO impressed. Never would’ve imagined one day almost every game would be playable.
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.