that's true -- thanks to the free win32 api implementation wine, x86 userspace emulators like qemu or box86, and piracy for drm-laden titles.
decades from now, windows games will be runnable on then-current platforms just like you can now run them on your android or arm macos device.
Edit to add: I also run DOS games like Ultima Underworld, Master of Orion 2, etc in DOSBox; things are already pretty good, but I will point out two other examples to argue for releasing of source: Jagged Alliance 2 and NeverWinter Nights. Both games released for Linux, but only JA2 had a source release eventually, and it still runs, because having source gives you that. Meanwhile, I still can't go back and replay NWN.
Also, if you only allow correctness-preserving transforms, why would you need an LLM in the first place? Just apply those correctness-preserving transforms directly (that's basically how recompilers work, which have been successful in doing that since the late 90s)
2. The aim is to apply the transforms in such a way that you get different code, which is still efficient, or maybe even more efficient. This is where you rely on the "intuition" of the LLMs. No guarantees there, that's why it was a question.
I fail to see how an LLM could magically improve that.
Yes this is oversimplified as wine is more complex than most games, and also there will be regressions and stuff as you can't test every Windows game ever every time you change something in wine, but still.
It would probably be easier for a game to just target the libraries Wine depends on, or even better, some smaller and more "least common denominator" abstraction layer (e.g. think libao for audio) sitting on top of the same libraries. While you can see Wine as de facto providing such an abstraction layer (e.g. you can switch audio drivers, video drivers, etc. in Wine), they are forced to expose an API whose evolution they don't control (Win32), which is something that long-term is doomed to fail.
I.e. something Wine-like for Linux ABIs themselves that games use would be great.
You are confirming that it is a good analogy. If some lib changes its ABI, in the wine case you need to fix it once: in wine. If you have 2000 Linux ports of games, you need to fix it 2000 times.
Your libao example is exactly the problem we currently have on Linux. Nothing is really stable, api and abi breakages happen almost everywhere. You can be careful and pick projects that promise to never break abi compat only to still get disappointed by at least one eventually.
And while win32 is not under your control regarding new features, it is by far the most stable userspace api and abi in existence.
See also: https://news.ycombinator.com/item?id=32471624 (article and comments)
In 2001 I wrote: "Those irrational people who reject Wine for purely political reasons, are doing much more damage to Linux than Wine will ever do. They're trying to argue that trivial invisible implementation details matter so much to users, that they would reject Linux if their favorite games weren't native ports, even if they ran under Wine. That's totally ridiculous."
I won't name names (because they're easy to guess), but some previously anti-Wine people are still around, and doing great work! And Wine didn't prevent that from happening, or destroy native Linux gaming.
Oh what the heck, ok, I will name one name of one anti-Wine person who's completely disappeared from the tech scene, because he was a dishonest exploitive lying scumbag lawyer who lined his own pockets instead of paying his hard working, talented, and fanatically dedicated employees (ahem make that contractors who he led to believe they were employees), who he deceived and screwed over financially and legally, getting them in undeserved trouble with the IRS, so he deserves to be mentioned: Scott Draeker.
https://en.wikipedia.org/wiki/Loki_Entertainment
https://www.eurogamer.net/a-loki
https://games.slashdot.org/story/01/10/28/1437229/lokis-drae...
https://www.linux.com/news/lokis-draeker-if-i-had-do-it-over...
>NewsForge: Or how about the TransGaming model of using WineX?
>Draeker: The arrival of TransGaming to me is the clearest indication that Loki failed to jump-start a Linux gaming industry as we’d hoped, because TransGaming has nothing to do with Linux games. Their message to game developers is: “Use DirectX and develop for Windows. We’ll help you sell your Windows products to Linux users.”
>TransGaming’s strategy is the same one Corel used in its Linux applications business. In the end I don’t think they’ll be any more successful than Corel was.
https://www.osnews.com/story/211/lokis-draeker-why-run-windo...
>Loki’s Draeker: Why Run Windows Games on Linux? Eugenia Loli 2001-10-24 Games 5 Comments
>“Competitor Scott Draeker isn’t impressed with TransGaming Technologies’ plan to use its version of Wine to get Windows games to work on Linux. […] Not so fast, says Draeker, whose Loki Entertainment has been the flagship company of that “traditional” approach. Draeker has doubts about games running on Wine working as well as games actually made to run on Linux. Although Loki filed for bankruptcy back in August, the company has continued to release games, including Kohan: Immortal Sovereigns in late August and Postal Plus ‘coming soon.’” Read the rest of the article on NewsForge:
https://web.archive.org/web/20011120221025/http://www.newsfo...
Loki - "we're not quite dead yet": Filed for bankruptcy protection not bankruptcy, but future still looks bleak:
https://www.eurogamer.net/article-31053
Loki: A promising plan gone terribly wrong:
https://archive.ph/20020418225227/http://www.linuxandmain.co...
Chris Chapman @retrohistories tweets quoting and summarizing that article:
https://twitter.com/retrohistories/status/142254664440337203...
>Loki was founded by Scott Draeker, an ex-lawyer with an ambitious plan: port already-successful PC games and sell them to Linux users.
>Yup. Sell games to a niche market (particularly in 1998) best known for their conviction that software should be free.
>Digital downloads weren’t really a thing back then (broadband adoption wasn’t there), so, like everyone else, they produced boxed copies. But these were hard to get hold of, especially outside the US. Loki’s global distribution network was small, further limiting sales.
>They burned through money like it was scrap paper, spending extravagantly and massively overestimating demand. They borrowed money from a friend of an employee and bought a projection TV. Late in the company’s life, when they couldn’t make payroll, they kept buying furniture.
>"Though its biggest seller not handled by MacMillan had moved only 5,000 copies, Draeker would order 12,000 to 15,000 copies of new games. These cost money to duplicate and package and, now, money to warehouse. The biggest miscalculation came with Quake III Arena, originally published by id Software. Draeker thought that a "limited collector's edition" shipped in a tin box specially made in China would be just the ticket -- so he ordered 50,000 units, making it the least limited of all of Loki's editions. About 7,000 units sold; most would be unloaded on a liquidator later. The miscalculation cost the company a quarter of a million dollars at a time when it was having difficulty meeting payroll."
>Chapter 11 wasn’t the end for Loki; they restructured and stayed operational for another five months, but not enough people were buying their games to get them out of the hole they were in.
>Then, suspicious transactions and negligent bookkeeping were uncovered.
>Coworkers who thought they were employees were told that they were contractors, and that they personally owed the social security taxes they believed Loki had paid on their behalf all along.
>Even more serious were the large sums of money transferred to Draeker and his wife.
>"So it was not until January that Loki's employees learned that they hadn't been employee at all. Instead of W-2 forms, they received 1099s, which is what are sent to outside contractors. The significance is that Loki employees who believed that withholding and social security taxes were being taken from their pay -- and who had been paid (when they were paid at all) an amount reflecting wages with those deductions having been make -- now learned that instead their pay had been reduced by the amount that would have been paid for those purposes, which now they had to pay themselves, because Loki hadn't."
>Seriously, you gotta read this account of some of the dubious behaviour that happened at Loki. It’s like a true crime story where the culprit got away.
>"Asked if Loki had recorded those erroneous transactions, Draeker replied, "We didn't have anyone keeping records at that time. It was -- it was in the bank statements, the record of that." Those bank statements had not been kept by the company. Additionally, the company was apparently unable to produce any financial records for the period from September 1999 to May 2001. The deposition took on a surreal air at times, with Draeker refusing to say whether or not he is a lawyer and in one spectacular moment testifying that as president of Loki he could say how much had been paid to Scott draeker and when, but as Scott Draeker he could not say whether he actually received the money. Yet when asked if, shortly before the bankruptcy filing, Loki had paid him $13,000, he replied, "Uh, as I said before, there are several occasions on which Loki did pay me. And I don't recall specific dates or amounts."
[...]
Also, I wrote this on slashdot in 2001 about my own experience with Scott Draeker:
https://games.slashdot.org/comments.pl?sid=23108&cid=2491410
>I worked full time at Maxis on The Sims for three years, and all that time I kept the idea of porting The Sims to other platforms in mind. So I wrote code as portably as I had time to, and thought a lot about what would need to be done. I evangelised to my co-workers and managers at Maxis about how I thought Loki would be the ideal company to port The Sims to Linux. Since there really isn't much demand for a Linux port, I proposed doing a Mac port in a way that would facilitate them both. Before The Sims was ever released, I wrote and sent a proposal around Maxis, outlining how to port The Sims to the Mac and Linux, using SDL and Open GL.
>I met Scott Draeker at the Game Developers conference on March 7 2000, about a month after The Sims shipped on Feb 4. I suggested that Loki port The Sims to Linux, because I was optimistic that it was going to be a popular game. He didn't seem to think so, and brushed me off, with a "go away kid, you're bothering me" attitude.
>But I gave Scott Draeker the benefit of the doubt, that he was just tired after a long day in the trade show booth, and not really as curt and indifferent to the idea as he seemed.
>Once The Sims shipped, I left my full time job at Maxis to work on some of my own projects, but I kept working on The Sims for Maxis as a contractor. I worked on content creation tools, developed Transmogrifier and other stuff. I still have legitimate access to The Sims source code, and I keep Will Wright up to date on what I'm doing.
>As a proof of concept, I started porting The Sims to Linux on my own time. I hoped to overcome the skepticism of some people at Maxis, as well as Scott Draeker at Loki, by demonstrating that it was indeed possible, and experimenting to find the best approach empirically.
>My goal was to find the best approach to getting The Sims to run on Linux. Not just to use one particular technology or another. The end result is what matters most, not the way it's implemented.
>Thanks to the encouragement of John Gilmore, I certainly did consider using Wine, but at the time it was nowhere near sufficient. (But since then, Transgaming has made astounding progress with Wine, and it's now obviously quite sufficient, to my delight.)
>So I used SDL to do a native port of The Sims to Linux, and got most of the game running quite well, except for drawing the people and roofs (which would require hacking a system memory back end to Mesa), and sound (which would require using OpenAL, with which I hoped Loki would have been able to help me).
>I was actually quite surprised at how quickly I was able to get a native port of The Sims running on Linux. My previous experience porting SimCity [catalog.com] to Unix took a lot more time. But the tools are much better and computers are way faster now. And of course I was more familiar with the code base.
>I offered the results of my work to Loki on reasonable terms. They didn't seem interested. I talked to some people at Maxis about it, and they said that Loki had been discussing it with Maxis, but they hadn't heard back from them in a long time.
>I finally got some brusque uninformative email from Scott Draeker, and we talked briefly on the phone, but he said that he was really busy, he had a lot of paperwork in progress that had to be finish, and he'd get back to me some time. So I stopped working on the port, and waited to hear back from him...
>I considered approaching other Linux game companies about porting The Sims to Linux, but decided to wait, because I still believed Loki was the best company to do it, and I did not want to undercut their ongoing negotiations with Maxis. Just the opposite -- I encouraged Maxis to quickly reach a fair deal with Loki, because I believed we could work together to get it to market fast. But Maxis wasn't the only company dragging their feet.
>Months later, I finally read on the net that Loki had decided not to port The Sims to Linux, because "Maxis wanted too much money". By that time, The Sims had been topping the charts for months, so of course Maxis was asking a lot for it.
>What I didn't know at the time, was that Loki was soon to declare Chapter 11. So it was actually a combination of Maxis wanting a lot for it, and Loki not having any money. But of course Draeker didn't mention that fact at the time.
>But fortunately, my time and effort porting The Sims to Linux was not wasted, because Maxis needed The Sims to run on Linux, as the multi-player game server for The Sims Online.
>So I used the original port at a guide, and more cleanly ported and optimized the newer Sims Online code to Linux again, making a headless build without all the graphics (removing SDL and DirectX). But the Linux build of the code is for Maxis's internal use on their servers, not as a commercial product for Linux.
>I made the same code base compile on both Windows and Linux, and both with or without graphic. The SDL graphics code still works on Linux, but it's only used for diagnostic and debugging purposes, and not for production.
>It's nice to run the graphical build of the Linux server in order to see what the server's doing during development. But the production server can't require a connection to an X server, and doesn't read in any graphics, because many must run on the same machine in parallel.
>Even though Loki blew their chance to port The Sims to Linux, I still wanted to see it happen anyway. But because so much time had passed since the release of The Sims, I would rather put my efforts into finishing porting The Sims Online client to Linux, and work with some other company than Loki.
>But I discussed it with Will Wright, and he explained to me in his reasonable, thoughtful, well considered manner: a native port of The Sims Online client to Linux would not be practical as a commercial product, because of its nature as a dynamically updated online game.
>The way The Sims Online and many other online games work, is that the server and the clients all run the same deterministic simulation in lock step, funneling any user requested changes through a central "headless" server, so the actions can be scheduled to happen at the same time in all parallel universes.
>So the server simulation and protocol must be EXACTLY the same as the clients, or all hell will break loose. Any online game, no matter what the architecture, requires that the client and the servers be in sync. That's not so hard if the game is trivial like Othello or Quake, but The Sims network protocol is much more complex and quite sensitive to incompatibilities.
>So there is absolutely no way to support any more than one client executable, because the clients and servers must be updated together in real time by downloading patches, just like Ultima Online and other games.
>In order for there to be a Linux port (or a Mac port), it would necessarily have to be done in-house at Maxis, built off of the same code tree, developed in parallel.
>It is simply not possible for a third party developer like Loki to stay in sync with the ongoing development at Maxis of The Sims Online. That would require enormous overhead and resources on the part of Maxis, all for an extremely negative return on investment: it would extremely complicate and slow down the development process, require extra programmers, quality assurance people with Linux skills, etc.
>Cross platform development requires a LOT of overhead -- please believe me if you haven't tried it. The gross income from selling Linux clients would be infintesimal, and would never outweigh the enormous cost of development. There is absolutely no way EA would ever allow Maxis to flush their stock holders' money down the toilet like that.
>That is the harsh, real, undenyable reason that Wine is the most practical and economical way to run games on Linux.
>I am quite pleased that Transgaming has developed Wine so far that it can now actually run The Sims! What's wrong with one Linux company coming up with a free and practical implementation of a great idea, that puts another Linux company out of business? Think of it as evolution in action, to quote somebody whose name doesn't deserve mentioning.
>The way Transgaming has improved Wine is so generally beneficial, that running The Sims Online on Linux the very day it's release on Windows, is now practically in the bag! With Loki's pace and approach, there was never any hope of that.
>The thing that matters most is the fact that a game DOES run on Linux, not HOW it's implemented. Real People in the Real World don't care about religious issues like if it's running under Wine or if it's a native port. It takes over the whole screen anyway, so what does it matter? The end experience is the same.
>Thanks to the generality of Wine, now there exists a whole spectrum of solutions, from binary emulation, to recompilation, all the way to native porting. Wine could be an extremely useful tool in the process of doing a fully native port.
>Those irrational people who reject Wine for purely political reasons, are doing much more damage to Linux than Wine will ever do. They're trying to argue that trivial invisible implementation details matter so much to users, that they would reject Linux if their favorite games weren't native ports, even if they ran under Wine. That's totally ridiculous.
>The fact that a game runs on Linux at all, is MUCH more important than whether or not it's a native port.
>Another advantage to Transgaming's Wine approach, is that all the existing free external tools like Transmogrifier, SimShow, Facelift, Art Studio, Home Crafer, Menu Edit, File Cop, and the many third party tools, will all probably run under Wine. And if they don't, Transgaming considers it a bug in Wine, and wants to fix it. Most of those tools will never be ported native to Linux, so the only way to use them is though Wine.
>I just can't believe that people would attack Transgaming for all that they've done and given back to the community. The alternative is for Linux to simply hold its breath and go without most games.
>The consequences of that alternative are dreadful, and much more harmful to Linux than the imaginary consequences of Wine. Now that Wine has been improved enough to run games like The Sims, it has so many other wonderful uses as well. Why would you ever consider sacrificing all that?
>It's not worth attacking Wine out of political correctness, in order to wait around forever for native ports that will never happen. Please don't cut off your nose to spite your face.
>-Don [donhopkins.com]
[...]
GNU/Linux following OS/2 steps on Windows games support, will find the same fate in game studios adoption.
It is quite telling that despite all game related NDK APIs being available on GNU/Linux, hardly any studio bothers with making their Android games available on GNU/Linux.
What does this really say, other than even if it was literally technically zero-cost to port a game to Linux, studios would still not bother about it ?
(This is ignoring the fact that I rather doubt we are at the "zero-cost" level and that Android has probably the worst backward compatibility of them all)
Actually, not even the studios that were invested into Stadia, cared about GNU/Linux, even though Stadia was mostly Linux based.
Valve says otherwise.
Steamdeck, however, came out last year and it was a sensible choice by Valve to support Wine and Proton and here’s what’s different.
Steamdeck is a platform that happens to run Linux as a full OS and Platform, and Wine in 2023 basically makes Linux (or at least Steamdeck) as another device driver.
Steamdeck is also a poor platform for PC gaming; but why is Microsoft is getting involved and helping? Perhaps its because PC gaming is a drop in the bucket compared to handheld and mobile.
If Valve remains committed with dedicated hardware and marketing—-and this is a big if—then it becomes another power console and platform.
The difference here is maybe Linux will get some of the crumbs and benefits.
The only thing Microsoft is helping with, is exposing XBox Cloud streaming, which again isn't Linux.
https://support.microsoft.com/en-gb/topic/xbox-cloud-gaming-...
https://arstechnica.com/gadgets/2023/04/handheld-mode-for-wi...
By the way, Linux is your strawman; not mine.
I'm moving my gaming and desktop experience to Linux because of this though I admit it's at a snail's pace.
More importantly: Office 365 is becoming more and more web-first: The only reason to use it within Windows today is because of the legacy add-ins, which Microsoft is slowly deprecating.
On its current trajectory, I don't see a future where Microsoft Windows remains relevant.
You know, given that Unity and Unreal engine have been touting cross-platform for years and even Activision is making a half-hearted attempt here.
And because the PC gaming experience has been degrading for the past 4-5 years. It's not just user hostile, it's become hostile to gamers.
Windows and the PC isn't the platform for great games like it used to be, because it actively gets in the way.
That doesn't mean Linux is automatically the answer, but there's an opportunity here because Microsoft has made multiple missteps in the past few years specifically with regards to games.
You don't seem well prepared for the FOSS crusade.
Games thrive on consoles; isn’t that how Steamdeck is positioning itself?
And didn’t you just say consoles outweigh PCs already? And why are consoles consistently in the lead?
You made this a Linux only discussion, not me. I'm perfectly happy if Wine proves to be reliable enough for my games.
In fact my original post was an anecdote (me). For some reason you chose an anecdote to make a series of personal attacks and unwarranted generalizations, but I'm happy to debate and bite because it's a fun topic for me personal attacks notwithstanding.
That is entirely wrong.
It is not because your latest distribution does not provide old/antique glibc by default that it means you can not run it.
It is currently pretty trivial to get a 20 years old glibc (or whatever library) recompiled under Linux to run your old game and call it a day.
Software like Nix nowadays even make that surprisingly easy with sandboxing.
That is currently the strength OSS and something you will never be able to do on Windows. As long as the version used is known and the source not lost: Software lives forever.
Just grep a kernel's Kconfig and see how many entries claim "this will break binary compatibility".
Even compilers are not that good at building old software.
Even old compilers can be boostrapped the same way.
Sandboxed prefx-install package manager like spack and Nix also allow you to do that without too much pain currently. They also give you the possibility to generate full featured Linux images if necessary for QEMU for instance.
That said: It is true they do not do it by default, it requires configuration (probably due to a too small userbase I guess).
I wonder if the userbase on that dedicated to old games/old app/old tools would be enough to dedicate a project on that entirely
You'll hit build issues, bootstrap issues (at which point you'll likely need an old Linux on a VM), kernel issues (which will force you to either patch the kernel, the libc, or both), and then a myriad of desktop integration issues, which is as usual the pain point and the main reason I always say static linking is absolutely useless for forward compatibility. For example, the game will try to set a rare resolution & refresh rate using Xrandr (good luck!), or will try to use OSS (for which user-space emulation with LD_PRELOAD is almost always useless, the in-kernel one prevents you from using pulseaudio, and CUSE doesn't support mmap which a shitton of games use), or even expect some specific behavior from the window manager, etc.
With more recent software, you'll hit issues with the software expecting some D-Bus services e.g. such as project utopia (yet another Linux desktop compatibility disaster that has been quickly forgotten by everyone involved, except for the software that decided to embrace it and now will never run again). In these cases building the libraries is only half the way...
That said, it's still true that a lot of times having the source available for all the underlying libraries is what makes these things possible _at all_.
Nix offers more than just prefix installs. It offers:
1. Reproducible builds of past packages and all of its dependencies down to the compiler that was used to build it.
2. Reproducible configuration of an entire distro provided by NixOS. It can also build VMs from NixOS configuration. So running an older kernel or DE is hardly an issue in the rare case this is required.
3. The ability to treat package definitions as code. You can take an existing package or its dependency and modify it however you like with a few lines of code. Tedious tasks like modifying rpath are abstracted away. It makes iterating on packaging work easier and less error prone.
4. Large binary cache provided by the NixOS Foundation. Binary builds of packages dating back years are currently available. This is helpful because it greatly speeds things up.
All of these things reduce the amount of work required to run old software. And new ones too.
Nothing that you mentioned is absolutely of use and is just going to get in the way. For example, the kernels you are going to need to use likely don't even have NPTL. No ELF exec in the NixOS "binary cache" will even work without NPTL; NixOS did not exist during the LinuxThreads eras.
Reproducible builds are absolutely useless here; I have the exact binaries that I want to run already, and most of the solutions are going to require patching the underlying libraries while still running the same game binary, practically the complete opposite idea to "reproducible builds and reproducible dependencies". You are going to spend more time fighting the package manager than the actual problems. How much does NixOS help running games which require OSS? Old versions of OpenGL that your graphics card now supports only poorly?
Static linking and NixOS may have its usefulness somewhere but definitely not here. They are not guarantees of long-term compatibility, and may actually hinder it (by preventing patching of the underlying libraries, and enforcing deviations from LSB that a lot of software can't cope with).
That is not at all what I wrote. I think I made myself clear in the first three sentences from my previous comment.
> Nothing that you mentioned is absolutely of use and is just going to get in the way.
I disagree. Making it easy to recreate old software environments is a huge time saver when it comes to running old software. "Absolutely of no use and is just going to get in the way" is a baffling statement. What's the easier alternative then? Patch the latest versions of software to make it compatible with the old ones?
And I repeat, I said time saver, not a magic wand that solves every exotic problem. And the LinuxThreads thing isn't an inherent problem with Nix either. Software made after Nix can benefit from its reproducibility.
> Reproducible builds are absolutely useless here
> You are going to spend more time fighting the package manager than the actual problems.
> by preventing patching of the underlying libraries
The exact opposite is true. Nix makes it easy to use previous package definitions as a starting point and modify it to fit your needs. Applying a patch to a dependency is only a few lines worth of Nix code. Compare that with other package managers, where you have to fork a whole world's amount of package definitions in order to apply changes to a dependency few levels deep. Also see point 3 from my previous comment.
> enforcing deviations from LSB that a lot of software can't cope with
There are countless ways to deal with this. If source code is available, then Nix supplies the adequate configure flags. This works most of the time. Grepping and patching is also an option. If source code isn't available, there's buildFHSEnv, steam-run, and nix-ld. Also, many applications support configurable paths.
The main advantage of Nix here is not its binary cache and reproducibility. It is Nix's ability to bootstrap any compiler tool chain + coreutils + kernel from scratch with just a bit of line of config.
Nix allow you to do what you would normally with a chroot but under steroid. It is not a magic bullet, far to be, but one order of magnitude easier to setup the exact tool chain you want than with anything else.
Most path related problems can be solved with a bunch of link and/or patchelf.
> will try to set a rare resolution & refresh rate using Xrandr (good luck!), or will try to use OSS
On this your are perfectly right. That will not protect you against this kind of crap related to exotic dependencies.
On that aspect Windows again is not much better (probably worst). Good luck to try to run in 2023 an old game that has a dependency on Novell IPX, an old version of Nvidia PhysiX or harcoded assumption on the GPU type
Yeah.. no. I am surprised people would still believe the claim that Win32 has "good backwards compatibility", specially for games, when even the TFA is claiming that a Windows 7 game is _not_ going to work on Windows 11 without "maintenance".
I'd not go as far as say that all Windows 7 games won't work, but it is definitely a good chunk. And I believe it's getting worse, with Windows 10 era games likely unable to run in "Windows 12". I already have at least one piece of software with runs in early Windows 10 but not in late Windows 10. People are resorting to literally use the Wine libraries in Windows to run old games. At this point, to target a Linux API doesn't seem that bad and likely would even be easier than having to maintain your win32 game AND wine.