SDL 3.1.3 Stable ABI Preview Release

[Chewi]

I am running steam on arch for years in 64bit and native libs, the steam client itself does not matter much if it is running in emulated mode, it's just a glorified browser anyways... Ir did I misunderstand the quote ...

You must have at least a 32-bit glibc installed. The rest will come from Steam's bundled runtime. There is no such thing as "emulated mode" in this context.

The browser part (libcef.so) is actually 64-bit these days, presumably because it wasn't feasible to build this for 32-bit anymore.

At the very least, the part that handles authentication will need to migrate. This involves certificates, which have expiry dates in the future. Or did you think your credentials were sent in plain text to untrusted endpoints? I have already said this, but nobody seems to want to hear it.

[xuedi]

I consider making it 64-bit to be much more important at this point.

I am running steam on arch for years in 64bit and native libs, the steam client itself does not matter much if it is running in emulated mode, it's just a glorified browser anyways... Ir did I misunderstand the quote ...

[billyswong]

No, most of the client is 32-bit, which has nothing to do with the games. It doesn't have to be, but that's my point. As others have said, we're getting to the point where you don't even need those 32-bit libraries for Windows games anymore thanks to new cleverness in Wine.

That just leaves 32-bit native Linux games, of which there are relatively few, and although I hate to say it, it will probably become more practical to run the Windows versions instead.

For programs that are still being actively maintained, time_t migration to 64-bit is not a problem. So the internal design in current Steam client doesn't matter. It is always about legacy binaries.

[Chewi]

Steam only need 32-bit support for Windows binaries. Windows binaries don't use the 32-bit time_t directly I think?

No, most of the client is 32-bit, which has nothing to do with the games. It doesn't have to be, but that's my point. As others have said, we're getting to the point where you don't even need those 32-bit libraries for Windows games anymore thanks to new cleverness in Wine.

That just leaves 32-bit native Linux games, of which there are relatively few, and although I hate to say it, it will probably become more practical to run the Windows versions instead.

[billyswong]

The relatively new time namespace feature in the kernel might suffice, although I've heard file timestamps can still be an issue. I haven't tried this yet. None of that helps the Steam client though. It's communicating with the outside world, so it needs to know what the real time is.

Steam only need 32-bit support for Windows binaries. Windows binaries don't use the 32-bit time_t directly I think?

[Weasel]

It's not that simple. 32-bit x86 binaries on Linux is built around a 32-bit time_t. Some distros are trying to deal with that by switching to 64-bit, but it breaks compatibility all over the place. It generally requires everything to be rebuilt. See this very recent blog post.

Except nothing stops Steam from using the 64-bit time_t even if the rest of the system uses 32-bit time_t, by using the 64-bit time_t APIs instead (kernel for example exposes both) or bypassing the libs (static linking is a thing).

Also, that's just about Gentoo. Debian already solved it, and Steam is officially only supported on Ubuntu or Arch Linux.

[Weasel]

Referring to this. They can. Or at least protected mode 32-bit.

Edit: Yes, true, this still does support 32-bit binaries.

That's about the OS itself being 32-bit. Stop spreading bullshit you've no idea what you're talking about.

If you can run 64-bit apps right now you're using a 64-bit OS already so that does not apply to you. Yet, you can still run 32-bit apps.

[kpedersen]

No.

You can't drop support for 32 bit binaries.

Referring to this. They can. Or at least protected mode 32-bit.

Edit: Yes, true, this still does support 32-bit binaries.

[Developer12]

Did you even read the rest of the thread? I didn't say anything about dropping 32-bit libraries because you're right about the games, but Steam itself still needs to go 64-bit.

It's not like I'm making all this up either. I know from a reliable source that Valve was looking into this over 4 years ago. It's a shame it's taken this long.

I'm here to tell you that steam going 64-bit is completely pointless. Read my post.

[Developer12]

I believe the x86_64 arch is going to drop its 32-bit support from the hardware level. This will probably be within the next decade rendering Microsoft's WoW64 redundant.

What we will probably see is something like qemu-static-i386 or plex (the same tech allowing x86* binaries to run on Arm). This is quite a nice middleground compared to the mixed architecture userland that Linux is currently using.

No.

You can't drop support for 32 bit binaries. This isn't ARM where the 32 bit instruction set is separate. x86_64 is a strict superset of x86, you literally can't write ANYTHING without using an instruction from x86.

What they're dropping is support for booting 32 bit OSs, which is an entirely different thing.