They keep a bunch of 32-bit libraries for backwards compatibility with older games that they launch. You can find numerous discussions about this in the Steam forums as well as on sites like Hackernews.
If you want, I can give it to you from a Valve employee:
We will not drop support for the many games that have shipped on Steam with only 32-bit builds, so Steam will continue to deploy a 32-bit execution environment. To that end, it will continue to need some basic 32-bit support from the host distribution (a 32-bit glibc, ELF loader, and OpenGL driver library).
Whether the Steam client graphical interface component itself gets ported to 64-bit is a different question altogether, and is largely irrelevant as the need for the 32-bit execution environment would still be there because of the many 32-bit games to support.
Maybe do some cursory research before talking out of your ass.
The steam client has nothing to do with the games it launches.
Process.Start() works on 32 bit or 64 bit processes…
They are on 32 bit because they don’t need to upgrade to 64 bit and it’s likely too complex to upgrade.
Visual Studio, which actually benefits from 64 bit, just recently upgraded because these massive software stacks are difficult to update.
They keep a bunch of 32-bit libraries for backwards compatibility with older games that they launch. You can find numerous discussions about this in the Steam forums as well as on sites like Hackernews.
If you want, I can give it to you from a Valve employee:
https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-267790879
Maybe do some cursory research before talking out of your ass.
You just proved my point.
Runtime environment != the steam client.
Starting a 32 bit process (ie, process.start()) means nothing to the 32 bit steam client.
They can upgrade the steam client to 64 bit without affecting the launched games. that’s the point I was making.
They just haven’t.