Comment by sylware | Hacker News Reader

Comment by sylware | Hacker News Reader

Prediction: Valve will cleanup the technical abomination which is the current steam client: clean 64bits (yeah, the core is still 32bits...), libdl-ing all its system deps (yeah, it is still statically loading libgl...), static libstdc++ and static libgcc to avoid those horrible ABIs, shell scripts with program helpers and conservative usage of command options and not bash scripts using command niche options (often gnu only, or alternative breaking, for instance alternatives of the "official xz"). Ofc, beyond compile-time OS abstraction tables of functions, proper runtime fallback tables of functions (wayland->x11, vulkan->GL->CPU), but since libcef (the steam client is moving to libcef) is blink, they don't do anything, google seems to do everything here (hope I am wrong).

Ofc, all game engines will be coded properly the same way. It seems unity3D is doing exactly that (but their vulkan3D backend seems far to be on par with their glcore backend).

Elephant is the room: c++ is not mean for binary-only games on elf/linux since the static libstdc++ does not libdl (dlopen/dlsym/dlclose) its system dependency (unless it was fixed by c++ gcc devs and I missed it). absolute truth: c++ syntax has a toxic complexity, not to mention its absurd and grotesque _very few_ required compilers in size and complexity.

And of course: Silksong, Half-life 3, dota2 out of beta and more native AAA (irony).

I don't talk about proton, which does just displace the QA which should be done by the game devs on native elf/linux to the "proton devs" (probably a money sink hole for valve) which have to deal with the massive bloat and kludge, msft grade (yeah...), of its code and SDK. It would be more reasonable with a lean build of wine(win64 core)+only vkd3d(dx12->vulkan), but I guess few to no games would run on that. Heard proton has straight copies of windows components... which would make things even worse.

> the "proton devs" (probably a money sink hole for valve)

It's probably a ridiculous figure. However, compared to the amount Sony/Nintendo/Microsoft spends engineering their console runtimes, I bet it makes a lot more sense. It also helps that Valve doesn't have to maintain Wine by themselves, with various cross-platform stakeholders funding and making contributions. It's obvious that Proton/DXVK/Wine is a passion project for Valve, but much harder to tell if they're seriously threatening the idea of a "Windows runtime".

> Elephant is the room: c++ is not mean for binary-only games

I think I agree with you. Steam's runtime provides a lot of stuff (probably standardized libstdc++), so it's hard to truly evaluate how true this is. That being said... both Steam and Wine do a really good job juggling it. Steam works roughly the same on NixOS, Arch, Flatpak and Snap - that's a better starting point than most software clients get.

>if they're seriously threatening the idea of a "Windows runtime".

From my vantage point, it certainly seems successful. I finally ditched my Windows gaming-only PC last year. Granted, people like me are likely less than a single digit percentage of gamers, but we exist, and as Proton compatibility improves, the percentage could rise.

Yep, I'm in the same boat. I reserve my judgement though, since a lot of people are still Windows-first and Microsoft has yet to make a Hail-Mary powergrab for DirectX.

I advise a visit to OS/2 museum.

I guess it's a sinkhole, but its more of an investment for Valve's future. If Microsoft comes down hard with pushing the Microsoft Store, especially since they now own how many different game studios, Valve (and the other Launcher/Gaming storefronts) will be pushed out of existence. Now, while Valve continues to hold influence in how games are distributed online, they are finding a way to exist without Windows and Microsoft. Steam is the easiest way to get games to play on Linux, and people can (and will) jump the Windows ship and still be able to buy games from Steam, allowing Steam to weather any attempts by Microsoft to put it out of business.

It happens all the time: some c++ games are compiled for a shared libstdc++... which is not ABI compatible with the one from the steam runtime (this is well know issue:c++ ABI is HORRIBLE). Namely it breaks with the steam runtime shared libstdc++. I repeat: it has been happening ALL THE TIME IN THE LAST DECADE.

I usually ask their devs to use the '-static-libstdc++' gcc/clang option (and at the same time -static-libgcc), and this issue is gone... actually partially, because the static libstdc++ is not libdl-ing its system (module/version)s & (symbol/version)s (well, did not check if c++ gcc/clang devs did fix that) and this is a big problem too: the linker with use the most recent version of modules and symbols (and you cannot overide than unless properly using libdl with dlopen/dlsym/dlclose).

What is the problem with that: well, the game binaries will then refuse to load on system with glibc modules/symbols with "too old" versions... and I was hit hard with this: no more than 1.5 years... yep, this is filthy nasty. And yes, this is not limited to the static libstdc++, it encompasses the glibc modules too. Godot devs mitigate this by explicitely warning devs about this issue and provide some containers with a really old glibc in order to avoid too recent versions.

When you really look at this, I mean with a "final" perspective: the "right" way would be to eat the bullet, and I mean seriously: deprecate ELF DT_NEEDED (and static TLS). It means that if you want to get some services from the system shared objects, you must use dlopen/dlsym/dlclose (and deal with the versions). It would be those symbols will become hard defined in the ELF loader, like __get_tls_addr() for TLS.

We could manage to keep DT_NEEDED, but it means binutils ld MUST allow fine-grained version specification of modules(shared objects) and symbols... which it does not (or it was fixed very recently and I missed it, or I sucked and did miss it from the doc for years).

Ok, I did double check. It is even worse.

You cannot "officially" remove any symbol versions, but it does not matter: games must become pure ELF binaries, namely MUST NOT USE main() for the following reason:

A genius at IBM(redhat/sourceware) did break for good the glibc: From glibc 2.34 __libc_start_main symbol has 2 versions, GLIBC_2.2.5 and GLIBC_2.34, it means that any game exe linked against glibc 2.34 won't load on system with glibc below 2.34, if using main().

wow... those guys are msft "grade" in planned obsolescence.

I for one would be very happy if they clean up the 32bit parts. On Fedora I haven't been able to get rid of a start-up warning saying 32 bit libs are missing (installing them doesn't seem to fix it). Fortunately I can launch games and do Steam Link just fine, so it's more an annoying dialog to click "Ok" on. But it does break anytime they push updates as Steam can't restart itself. I also occasionally have to `pkill -9 steam` as it doesn't properly handle signals so will ignore anything it can. Minor complaints to be sure, but would be great to get cleaned up.

> c++ syntax has a toxic complexity

irrelevant.

any language that allows polymorphism (i.e same name for a procedure call with different versions used for different argument types) has to do some sort of naming trick to make this possible (since the idea is unknown at assembler or linker level). what makes c++ tricky for linkage is almost entirely just this, which has nothing to do with c++ syntax at all.

Reply on news.ycombinator.com