Comment by ticulatedspline
23 days ago
Wine might be oddly self-defeating. Broad game support on Linux increases the viability of Linux as a desktop, which increases market share, which may result in developers creating Linux ports as a 1st class concern, which don't need Wine to run.
Wine's APIs are more stable than Linux's APIs, so it seems more plausible to me that Wine will become the first class target itself.
I wouldn't be surprised if Wine eventually becomes more stable than Windows.
I've experienced multiple instances where (so I heard; I don't use Windows) a Windows Update completely broke a game on Windows for everyone, but Wine/Proton kept running it just fine. So we're already there in some sense.
1 reply →
It feels like it won't be long before Microsoft starts helping with that (by making Windows less stable, not improving Wine).
2 replies →
Windows 14 will just be a linux distro with wine acting as backwards compatibility.
5 replies →
Wine actually does run some ancient Windows games better than Windows 11 itself.
14 replies →
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!
That will never happen.
Ever since Proton came along, it has been a quiet agreement that Win32 APIs are the best target for Linux support.
Building against the Steam runtime containers seems like the other route, which also gets you more stability.
I agree with this take. Wine/Proton might become something akin to a runtime for games, running on many platforms and consoles. This means devs might stop targeting windows directly, but rather they target wine and you'll need that for your games on Windows.
Valve nudges developers to ship/support their "one best version" of a game, and trust compatibility layers to make it work for everyone else.
For x86, that's Windows. For mobile/VR, it's Android.
People always say this to shit on glibc meanwhile those guys bend over backwards to provide strong API compatibilities. It rubs me off the wrong way.
What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.
Such application could be rebuilt to work with an older glibc as the API is stable. The ABI is not which is why the application would need to be rebuilt.
glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed. Maintaining a stable ABI mostly helps proprietary software where the source is not available for recompilation. Naturally the gnu guys building glibc don’t care about that use case much.
I guess you didn’t mention glibc in your comment but I already typed this out
> What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.
Is this correct? I think you perhaps have it backward? If I compile something against the glibc on my system (Debian testing), it may fail to run on older Debian releases that have older glibc versions. But I don't see why an app built against glibc 2.12 wouldn't run on Debian testing. glibc actually does a good job of using symbol versioning, and IIRC they haven't removed any public functions, so I don't see why this wouldn't work.
More at issue would be the availability of other dependencies. If that old binary compiled against glibc 2.12 was also linked with, say, OpenSSL 0.9.7, I'd have to go out and build a copy of that myself, as Debian no longer provides it, and OpenSSL 3.x is not ABI-compatible.
> glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed.
If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux. And I wouldn't blame them.
8 replies →
No other operating system works like this. Supporting older versions of an OS or runtime with a compiler toolchain a standard expectation of developers.
15 replies →
I personally believe we should just compile games statically. Problem solved, right?
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).
1 reply →
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 actually think it'll be the opposite. Even for games that have native ports I pretty much always run the Windows version with Proton, since that just tends to be more stable. People develop against the Windows API because it's familiar and somewhat unchanging, and that's fine since Proton does such a good job running it.
This is the very definition of "a good problem to have."
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.
Unlikely. Games need a stable ABI and Win32 is the only stable ABI on Linux.
Proprietary software needs a stable ABI. Not games.
DOOM runs on any Linux system since forever because we had access to the source. You can build it for Linux 2.6 and it’ll probably still work today.
Sadly most games are proprietary
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.
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. :(
2 replies →
> Proprietary software needs a stable ABI.
Open source software also needs a stable ABI because:
a) i don't want to bother building it over and over (not everything is in my distro's repository, a ton of software has a stupid building process and not every new version is always better than the old versions)
b) a stable ABI implies a stable API and even if you have the source, it is a massive PITA to have to fix whatever stuff the program's dependencies broke to get it running, especially if you're not the developer who made it in the first place
c) as an extension to "b", a stable API also means more widely spread information/knowledge about it (people wont have to waste time learning how to do the same tasks in a slightly different way using a different API), thus much easier for people to contribute to software that use that API
People who keep parroting this clearly have no experience of gaming on linux.
I am playing both modern and old games on Linux. Games outside a super narrow enthusiast realm are always closed-source (even indie ones) and it's going to stay like that in the foreseeable future, that's just a fact of life and gamedev incentives and specifics.
Please elaborate.
4 replies →
Are you able to run any of the old Loki games on Linux these days?
1 reply →
Quiet the other way around. Wine being good will reduce incentives for game studio to produce native Linux ports.
Wine has always beem a bandage not a final thing. Something to drive exactly this transition to better. Through wine ive been able to transition many colleagues accross because software they need will work as they expect it to in linux and everything elese is an arcane mystery to them anyway. This means one less network effect contributing win user. Most also experience a massive jump in tech literacy as a result of the move, since a system that doesn't wall you out at every step lets you passively learn more.
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.
In many cases for game devs/publishers "supporting Linux" now means making sure the Windows build runs well under Proton.
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
There always will be old games that will never be ported to Linux.
It's interesting when old Windows games run better in Wine than in actual Windows 10/11.
It's even more interesting when the latest Windows games run better in Wine than in actual Windows 10/11.
If you game/app runs on Wine, doesn't that reduce the pressure to develop a Linux port?
Possibly but does it realistically matter? I don't care why my games run on linux I just care that they do. I encountered a few cases where the native version was inferior to the wine version (Cronos is one example). With wine improving there is very little downside to just using it.
Could there ever be a killer app for Linux? One that would cause a not-insignificant number of people to decide that Linux was worth switching to, even if there was some pain of moving away from Windows?
short term yeah, probably hurts native ports since "why bother". Long term though if the market share for Linux is particularly high I could see more native development.
Either way my comment is intended as more humorous than truly insightful or prophetic.
A solution to itself
Gotta get there somehow.
OS/2 part deux
Sorta, kinda, but not really.
OS/2 may have been a better Windows than Windows during the Warp days 30-ish years ago. It was also a very competent operating system in its own right.
We all know the story:
It never had a broad base of native applications. It could have happened, but it did not happen. Like, back then when Usenet was the primary way of conducting written online discourse, the best newsreader I had on OS/2 was a Windows program; the ones that ran natively on OS/2 weren't even close.
And OS/2 never had support from a popular company. There were times at OS/2's peak (such as it was) when it was essentially impossible to buy a new computer with OS/2 pre-installed and working correctly even from IBM.
Linux, though? Over those same 30-ish years, a huge amount of native applications have been written. Tons of day-to-day stuff can be done very well in Linux without even a hint of Wine and that's been reality for quite a long time now.
The missing piece, if there is one, is gaming. It'd be great to have more native games and fewer abstraction layers. But systems like Valve's popular Steam Deck and upcoming Steam Machine are positive aspects that OS/2 never had an equivalent to. And since Steam is very nearly ubiquitous, companies that sell computer game software do pay attention to what Valve is doing in this space.
(And frankly, when a game runs great in some Steam/Wine/Proton/Vulkan shapeshifting slime mold abstraction stack, I really do not care that it isn't running natively. I push the button and receive candy.)
[flagged]