7 ms·

> People think of the PC as this completely invincible platform where once you get a PC version it lives forever that's true -- thanks to the free win32 api im

by 5- 3y ago

> People think of the PC as this completely invincible platform where once you get a PC version it lives forever 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.

shmerl 3y ago
Someone has to maintain Wine and all the rest. So it requires effort and isn't something simply guaranteed.
- 5- 3y ago
  of course. please donate (money or effort) to these important preservation projects!
- 867-5309 3y ago
  in the future, finding a compatible emulator version will be a lot easier than acquiring the original intended hardware
  - shmerl 3y ago
    It's already easier. My point is that someone has to keep the compatibility layers working on modern systems.
- pasc1878 3y ago
  TYo keep Wine going buy the commercial version of Wine - Crossover from codewavers.com
- amelius 3y ago
  In theory, can't an LLM be used to translate code from the original platform to the emulation environment, in such a way that there is no copyright infringement ?
  - JonChesterfield 3y ago
    If you define LLMs as magic portals for ignoring copyright law and also assume they're magically able to perform arbitrary code transforms defying compiler engineers, then sure.
    - amelius 3y ago
      You don't need arbitrary code transforms, just correctness-preserving code transforms.
      - dark-star 3y ago
        LLMs are inherently bad at this whole "correctness" thing...
        amelius 3y ago
        Well, not if you force them to use only correctness-preserving transforms. Just reject anything else.
        dark-star 3y ago
        So how would you prove that the transforms it conjures up are in fact correctness-preserving? 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)
        amelius 3y ago
        1. You write and prove the correctness preserving transforms yourself. They are low-level, so you only need to do a small number of them. 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.
- iforgotpassword 3y ago
  But that's one thing to maintain. With every game you port to Linux, you have one more thing to maintain and update to whatever shit breaks it on the userspace side 3 years from now. That's O(n) while maintaining wine is O(1). 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.
  - nobodyandproud 3y ago
    Then maintaining Wine is more like O(lg n).
  - shmerl 3y ago
    It would be nice actually to have a Linux own compatibility layer similar to Wine, that preserves old APIs same way Wine does for Windows ones. But so far no one is really planning to make such.
  - AshamedCaptain 3y ago
    This is a bad analogy, because Wine also has dependencies on various "Linux APIs". So technically if you maintain Wine you are also maintaining all the libraries Wine depends on, and so on. 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.
    - shmerl 3y ago
      The problem is maintaining long term compatibility which is what Wine is doing. Native Linux ABIs can break (soname changes and etc.) and unless someone keeps translating old ones into newer ones, it won't work. I.e. something Wine-like for Linux ABIs themselves that games use would be great.
- beardedmoose 3y ago
  Sounds like we need an all in one VM solution with GPU access, where the whole OS is embedded with the game and can run ontop of any OS providing there is a player for the VM itself.
DonHopkins 3y ago
The reddit linux gaming "community" used to be virulently anti-Wine. They considered it an atrocity.
- ekianjo 3y ago
  These people have completely disappeared
  - DonHopkins 3y ago
    You can be Pro-Native without being Anti-Wine. 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://en.wikipedia.org/wiki/Loki_Entertainment https://www.eurogamer.net/a-loki https://www.eurogamer.net/a-loki https://games.slashdot.org/story/01/10/28/1437229/lokis-draeker-on-winex-transgaming-and-more https://games.slashdot.org/story/01/10/28/1437229/lokis-drae... https://www.linux.com/news/lokis-draeker-if-i-had-do-it-over-id-create-linux-native-games/ 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-windows-games-on-linux/ 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.newsforge.com/article.pl?sid=01/10/23/013232&mode=thread 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 https://www.eurogamer.net/article-31053 Loki: A promising plan gone terribly wrong: https://archive.ph/20020418225227/http://www.linuxandmain.com/features/lokistory.html https://archive.ph/20020418225227/http://www.linuxandmain.co... Chris Chapman @retrohistories tweets quoting and summarizing that article: https://twitter.com/retrohistories/status/1422546644403372033 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 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] [...]
Asooka 3y ago
Yeah I was going to say Linux is a strange choice of platform for this project. While the kernel per se is solid, the userland has zero backwards compatibility. I expect his ports will bitrot and none will run two to five years from now, while the win32 versions will be kept supported in perpetuity. Though who knows, maybe this is what finally makes the Linux community start paying attention to backwar.. pffhahaha no I can't finish this sentence with a straight face. I have been using Linux for over 20 years now and am absolutely certain it will never be a stable target. Just compile for win32. Or wasm. Maybe one day wasm will be the stable desktop ABI.
- adev_ 3y ago
  > While the kernel per se is solid, the userland has zero backwards compatibility 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.
  - AshamedCaptain 3y ago
    It is not that trivial, and there have been breaking kernel changes that prevent running ancient glibc versions. Fortunately, glibc is open source, so you can actually patch it to run in older versions. 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.
    - adev_ 3y ago
      > 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
amelius 3y ago
Ok, how about iOS games?
- rowanG077 3y ago
  Couldn't choose a worse platform. The user isn't even free the install what they want.
rvba 3y ago
There is a problem of preserving online-only games - which work in the "game-as-a-service" model. Without a third party / pirate server the games simply wont work. Different thing is that a dead multiplayer game is a dead game, especially MMOs.
npsimons 3y ago
I mean, I've been running NES, SNES and GameBoy games on emulators (in Linux, natch) for decades now. Hell, I played through FF5 for the first time a few years back. 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.

by 5- 3y ago

shmerl 3y ago

Someone has to maintain Wine and all the rest. So it requires effort and isn't something simply guaranteed.

5- 3y ago
of course. please donate (money or effort) to these important preservation projects!
867-5309 3y ago
in the future, finding a compatible emulator version will be a lot easier than acquiring the original intended hardware
- shmerl 3y ago
  It's already easier. My point is that someone has to keep the compatibility layers working on modern systems.
pasc1878 3y ago
TYo keep Wine going buy the commercial version of Wine - Crossover from codewavers.com
amelius 3y ago
In theory, can't an LLM be used to translate code from the original platform to the emulation environment, in such a way that there is no copyright infringement ?
- JonChesterfield 3y ago
  If you define LLMs as magic portals for ignoring copyright law and also assume they're magically able to perform arbitrary code transforms defying compiler engineers, then sure.
  - amelius 3y ago
    You don't need arbitrary code transforms, just correctness-preserving code transforms.
    - dark-star 3y ago
      LLMs are inherently bad at this whole "correctness" thing...
      - amelius 3y ago
        Well, not if you force them to use only correctness-preserving transforms. Just reject anything else.
        dark-star 3y ago
        So how would you prove that the transforms it conjures up are in fact correctness-preserving? 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)
        amelius 3y ago
        1. You write and prove the correctness preserving transforms yourself. They are low-level, so you only need to do a small number of them. 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.
iforgotpassword 3y ago
But that's one thing to maintain. With every game you port to Linux, you have one more thing to maintain and update to whatever shit breaks it on the userspace side 3 years from now. That's O(n) while maintaining wine is O(1). 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.
- nobodyandproud 3y ago
  Then maintaining Wine is more like O(lg n).
- shmerl 3y ago
  It would be nice actually to have a Linux own compatibility layer similar to Wine, that preserves old APIs same way Wine does for Windows ones. But so far no one is really planning to make such.
- AshamedCaptain 3y ago
  This is a bad analogy, because Wine also has dependencies on various "Linux APIs". So technically if you maintain Wine you are also maintaining all the libraries Wine depends on, and so on. 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.
  - shmerl 3y ago
    The problem is maintaining long term compatibility which is what Wine is doing. Native Linux ABIs can break (soname changes and etc.) and unless someone keeps translating old ones into newer ones, it won't work. I.e. something Wine-like for Linux ABIs themselves that games use would be great.
beardedmoose 3y ago
Sounds like we need an all in one VM solution with GPU access, where the whole OS is embedded with the game and can run ontop of any OS providing there is a player for the VM itself.

DonHopkins 3y ago

The reddit linux gaming "community" used to be virulently anti-Wine. They considered it an atrocity.

ekianjo 3y ago
These people have completely disappeared
- DonHopkins 3y ago
  You can be Pro-Native without being Anti-Wine. 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://en.wikipedia.org/wiki/Loki_Entertainment https://www.eurogamer.net/a-loki https://www.eurogamer.net/a-loki https://games.slashdot.org/story/01/10/28/1437229/lokis-draeker-on-winex-transgaming-and-more https://games.slashdot.org/story/01/10/28/1437229/lokis-drae... https://www.linux.com/news/lokis-draeker-if-i-had-do-it-over-id-create-linux-native-games/ 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-windows-games-on-linux/ 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.newsforge.com/article.pl?sid=01/10/23/013232&mode=thread 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 https://www.eurogamer.net/article-31053 Loki: A promising plan gone terribly wrong: https://archive.ph/20020418225227/http://www.linuxandmain.com/features/lokistory.html https://archive.ph/20020418225227/http://www.linuxandmain.co... Chris Chapman @retrohistories tweets quoting and summarizing that article: https://twitter.com/retrohistories/status/1422546644403372033 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 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] [...]

Asooka 3y ago

Yeah I was going to say Linux is a strange choice of platform for this project. While the kernel per se is solid, the userland has zero backwards compatibility. I expect his ports will bitrot and none will run two to five years from now, while the win32 versions will be kept supported in perpetuity. Though who knows, maybe this is what finally makes the Linux community start paying attention to backwar.. pffhahaha no I can't finish this sentence with a straight face. I have been using Linux for over 20 years now and am absolutely certain it will never be a stable target. Just compile for win32. Or wasm. Maybe one day wasm will be the stable desktop ABI.

adev_ 3y ago
> While the kernel per se is solid, the userland has zero backwards compatibility 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.
- AshamedCaptain 3y ago
  It is not that trivial, and there have been breaking kernel changes that prevent running ancient glibc versions. Fortunately, glibc is open source, so you can actually patch it to run in older versions. 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.
  - adev_ 3y ago
    > 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

amelius 3y ago

Ok, how about iOS games?

rowanG077 3y ago
Couldn't choose a worse platform. The user isn't even free the install what they want.

rvba 3y ago

There is a problem of preserving online-only games - which work in the "game-as-a-service" model. Without a third party / pirate server the games simply wont work. Different thing is that a dead multiplayer game is a dead game, especially MMOs.

npsimons 3y ago

I mean, I've been running NES, SNES and GameBoy games on emulators (in Linux, natch) for decades now. Hell, I played through FF5 for the first time a few years back. 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.