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.
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.
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).
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.
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.
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.