Lots of discussions on this already, NoTuxNoBux and all that, but one thing I think is often overlooked is that Proton/Wine enables treating closed source games a bit like emulation roms, thus freeing the system around it to innovate.

What I mean with that is that binary backwards compatibility is a sort of poisoned sweet of the Windows world. It has resulted in the monstrous instable thing that Windows is, but admittedly is much better at running a few years old binary only software (although not perfectly though, ans in some cases WINE is better already).

In the GNU/Linux world backwards compatibility is usually much less of a concern as with open-source software a library dependency is usually fixed quite easily.

But with closed source game ports it becomes quite apparent that this model doesn’t work with unmaintained binaries, as Linux game binaries very often become unusable very quickly.

Of course in an ideal world all software was FOSS, but in our less than ideal world we need to think of ways to deal with this fact.

Of course GNU/Linux could become more like Windows in that regard (worst outcome IMHO), or some sort of containers could be wrapped around those games that include the older libraries.

Or we could just consider old windows games to be similar to ROMs for emulators and run them through Proton/WINE…

P.S.: in before WINE Is Not an Emulator ;)

  • UnreliantGiant@lemmy.ml
    link
    fedilink
    arrow-up
    6
    ·
    4 years ago

    I think Wine is a very important project. Not just for playing recent Windows-only games but also as a documentation of Windows APIs and to keep old software functional on modern systems.

    Linux binaries being so troublesome to get up and running is an interesting issue too. In my opinion many developers just do it wrong by dynamically linking their binaries and thus depending on specific libraries being available on the users OS. Instead they should ship their own libraries by statically linking them into the binary itself or using some start script that preloads those libraries from their own folder. This would fix the majority of issues people encounter with running random binaries. There could still be problems since the Linux desktop keeps evolving, so APIs that were available 10 years ago might not be there anymore. Examples of this would be OSS which was replaced by ALSA, and the current progression from X11 to Wayland. When developing something new this could easily be avoided by using a library like SDL2, which at the same time also makes it easier to write cross platform applications. That’s not a solution for abandoned or huge projects though

    • poVoq@lemmy.mlOP
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      4 years ago

      Yeah for sure there are ways to avoid many of the problems, but lets be honest: most ports are not of the highest quality in the first place and we can often be happy that it runs at all.