Nothing stops you from doing pacman -S wesnoth openmw endless-sky openttd openrct2 naev. Your definition of elf/linux binaries seems to be narrowly defined to r

Nothing stops you from doing pacman -S wesnoth openmw endless-sky openttd openrct2 naev. Your definition of elf/linux binaries seems to be narrowly defined to refer to proprietary games developed by professional game studios, who always had the ability to cancel Linux support at the drop of a hat. >It would have been 1 billion times cheaper, and saner, to write audit tools for ELF64 binaries in order to drive game devs at crafting clean binaries Are you sure? The man hours spent on Proton and wine and DXVK are nowhere near enough to port even a dozen triple A games. Even if they do, nobody is going to rewrite their renderer from DirectX to Vulkan just to support Linux, they will still rely on DXVK as a dependency. I don't remember which game it was, but they had an entire dev team to build a renderer just for Linux and they scrapped it, because at some point the Windows and Linux renderer diverged too much and that was the end of Linux support. I am often playing a bunch of games that were built with 'nw' and there is no Linux version for them and the chromium version they use often doesn't work, because Wine doesn't support CEF sandboxing. What I do is download a recent 'nw' release and just copy it into the folder and overwrite all the 'nw' related files and then it works. According to your comment, this is a great evil, since I am enabling these developers to not provide an explicit Linux release. Instead you're suggesting that they and I would save billions by not copying 'nw' into the folder.