Beamdog initially released only 32-bit native GNU/Linux versions of their EE games, which meant one would need to install multilib in 64-bit systems just to play a game. However they later fixed this by releasing 64-bit versions of the games. On Window$ this "problem" never existed because Window$ installs 32-bit libraries in a 64-bt installation without even asking you - and that's nothing compared to other things they do, actually.

Concerning WINE, you can certainly use it to play the EE games, but I would never do that. First of all the native GNU/Linux versions of the games work flawlessly, so I see no reason to use a simulation while I can play the games natively. In addition, WINE is 32-bit (the 64-bit version of WINE is only experimental), so going the WINE way also means you have to install (otherwise useless) 32-bit libraries in a 64-bit system.

Also, openssl 1.0 was not old when the EE games were released. It was certainly a thing back then. The fact newer version of openssl existed doesn't mean GNU/Linux distributions adopted it immediately. Add to this openssl is a security library, and you have a perfect reason to avoid switching to a new version right away. This is only done in bleeding-edge distributions, eager to adopt anything new, assuming "new" automatically means "better" - which is far from being true. Such distributions are prone to instabilities by definition, and if you use them you accept the fact problems can and will occur. sooner or later. So Beamdog did well to use openssl 1.0 back when the games were released. They did not, however, did well to keep doing that 10 years later, when even the most conservative distributions use openssl 1.1. Their 2.6.6.0 version of the games is simply unplayable as it is, except for very old systems which never upgraded their GNU/Linux.

At any rate, solving the incompatibility issue is easy. Just do as I said in my previous post and the games will run without any issue. If you have all their EE games, it's probably better to just store the old_libraries_needed in one folder, accessed by all the EE games. This only means in each game the line you have to add in start.sh script should be slightly modified to:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<add full path of old_libraries_needed here>

Dependency hell is always a problem on Linux, but actual bugs during an OS's lifecycle are quire rare IMHO.

Fair enough, but a native game is always going to be faster (albeit maybe not noticeably faster) than one that has to go through syscall and graphics API translation. We're talking about well done ports here, not shoddy ones.

32-bit thunking in Wine is actively being worked on. The days when 64-bit support was experimental are long gone.

Depends on your point of view. Shared libraries are the norm in GNU/Linux for a reason - although some distributions do deliver statically linked stuff by default. On the other hand, static linkage has the portability benefit. There is no "win-win" solution. As far EE games are concerned, the best solution would be to have the libraries needed in a separate package, installed once and used by all EE games. However I doubt this will ever happen because it comes with its own maintenance problems.

Very true. I have yet to encounter issues. No matter how some people hate Beamdog (I don't), it is undeniable they did a great job porting Infinity games on GNU/Linux, and their enhanced editions are better than any heavily modded original one.

That's not what I have seen when I tried WINE 64-bit, and that was like a year ago. Maybe things are better now. I certainly hope so.

Unless you use rolling release then there is no such thing as OS lifecycle. I assume that in case of BG:EE that old libssl was still included in Ubuntu LTS on release because it was "the default" most devs were aiming for? Now it doesn't matter anyway as they didn't bother to update builds and no one uses 10 years old Ubuntu nowadays.

Yes at least it should be in theory. Making well done port is apparently not always easy. Games after Feral Interactive treatment are quite known to perform worse as native and that's company dedicated to porting.

I did not experience this one, but it might be because I do not use their shipped libraries in the first place.

I think we all know the real solution for this kind of issue: keep proprietary assets, but release the engine under an open source licence ;)

On the other hand, I do expect support as long as the game/software is sold. Why am I giving them money if their product is no longer maintained?

---

The issue here is not that they used OpenSSL 1.0, but explicitly OpenSSL 1.0.0. That one was deprecated months before the release of their first Enhanced Edition game.

What do you think about shipping games in something like Appimage? Does it have any serious downsides? Because theoretically it should be both super easy to use for users (you don't need any technical knowledge at all) and solve all dependency problems.
Packaging for developers shouldn't be much more complex than preparing installers, maybe even easier because no need to test in different environments.

If GOG starts selling AppImage (or Flatpak, or Snap) instead of their regular installers, I would no longer buy games from them. I don’t really care about the installer format as long as I can extract its content like any regular archive, and turn that into native packages. But these new so-called "portable" systems would make that much harder.

I trust the maintainers of my distribution to provide regular updates to the libraries used by my games. I would not trust neither GOG nor game developers to provide such support for the libraries they ship.

GOG or Beamdog could simply include the needed versions and softlink them, as they do for other games, but I guess nobody considered it at the time. And won't bother with it now, sadly.

They are indeed better. And the end goal is to deprecate any 32-bit components and use 64-bit libraries to run everything, including 32-bit games, but there's still a lot of groundwork to be done before that becomes possible.

Funny, A lot of games have shown more stable and better performance through WINE than when run natively on Linux. It's not so cut and dry as "native = better" for this.

... as I said above, shoddy ports aside, this should not be the case.

In my experience native ones are often much better supported than WINE emulation (over hundreds of games but mostly a single Linux distribution, so this is of course biased). I especially love games like Warhammer 40k: Gladius - Relics of War where native Linux performances and stability are much better than the native Windows ones.

Out of curiosity, what are some games you are thinking about when writing about a better experience through WINE than the native Linux one?

Thanks for this! I couldn't get the ./play.it solution to work for me. Your solution was simple and effective.

...

Do you remember what did not work as expected?
If it was due to some bug, or unclear instructions, maybe we can fix this.