Please switch to 64 bit

[cbogus]

Yes, this over and over and over and there's even a Github issue[github.com] for it, but pretty please: switch to 64 bit already. Fedora has plans to drop 32 bit[fedoraproject.org] at one point and Ubuntu is trying to do the same[canonical.com] (but couldn't, of course), please make this happen. If only because of this:

$ dnf install steam

Install  178 Packages
Total download size: 139 M
Installed size: 543 M

....all 32 bit crap that was already in place as 64 bit, but had to be installed again as its 32 bit version :-\

[Zefar]

Αναρτήθηκε αρχικά από lsdninja:

Αναρτήθηκε αρχικά από Zefar:

I remember Valve commenting on this and Steam basically will not get any extra benefits from going 64 Bit. Because it can already do all of it's task on a single core without any problems.

On Macs Steam is 64Bit because Apple just decided that all 32Bit programs would be obsolete. But you know, typical Apple stuff.

Did they say that before, or after, switching almost the entire client over to CEF and therefore requiring stupid amounts of RAM because Chrom(e,ium) leaks like a sieve? XD

It was several years ago minimum. Also it still wouldn't matter if it became 64Bit and still have memory leak issues. We also have this where a lot of people are not getting this problem.

[thegreenpan]

I would prefer an X86 version as 64bit architecture only supports 64 bit software and 32bit architecture only supports 32bit software. X86 architecture supports both 32 bit and 64 bit software types. This is why there is a folder on C:\ called Program Files (x86) because programs in that folder use components of both 32bit architecture and 64 bit architecture to run. So if programs are run from that folder windows knows it needs to use emulation to interpret parts of the code or all of the code.
On the other hand programs in the folder Program Files match the default architecture that the system is designed to run. Nowadays that is usually that is 64bit. these days.
This means that if the current hosted steam platform where upgraded to 64bit that will immediately make all 32bit games on steam unplayable, and inaccessible by users.
This is why I would prefer an X86 vershion of steam as an upgrade to the current hosted platform.

[Satoru]

Αναρτήθηκε αρχικά από lsdninja:

Αναρτήθηκε αρχικά από Zefar:

I remember Valve commenting on this and Steam basically will not get any extra benefits from going 64 Bit. Because it can already do all of it's task on a single core without any problems.

On Macs Steam is 64Bit because Apple just decided that all 32Bit programs would be obsolete. But you know, typical Apple stuff.

Did they say that before, or after, switching almost the entire client over to CEF and therefore requiring stupid amounts of RAM because Chrom(e,ium) leaks like a sieve? XD

Seriously though, it's mostly just the bootstrapper and a couple of other things that are still 32-bit and don't really need to be 64-bit. Linux users just complain the most because it's more visible when something is 32-bit. That said, the fact that Valve is making a 64-bit clean client on one platform (because it doesn't give them a choice) and none of the others is still laziness on their part.

The point is that 64bt main benefit is access to memory over 2GB. Which isn't that relevant for a client that basically never needs more than 2GB to do anything. Asking for 64-bit 'for the sake of it' isnt that relevant. You're not getting anything out of it. There's no performance benefit since again needing to address more than 2GB isn't something the steam client needs

[Crashed]

Αναρτήθηκε αρχικά από Satoru:

Αναρτήθηκε αρχικά από lsdninja:

Did they say that before, or after, switching almost the entire client over to CEF and therefore requiring stupid amounts of RAM because Chrom(e,ium) leaks like a sieve? XD

Seriously though, it's mostly just the bootstrapper and a couple of other things that are still 32-bit and don't really need to be 64-bit. Linux users just complain the most because it's more visible when something is 32-bit. That said, the fact that Valve is making a 64-bit clean client on one platform (because it doesn't give them a choice) and none of the others is still laziness on their part.

The point is that 64bt main benefit is access to memory over 2GB. Which isn't that relevant for a client that basically never needs more than 2GB to do anything. Asking for 64-bit 'for the sake of it' isnt that relevant. You're not getting anything out of it. There's no performance benefit since again needing to address more than 2GB isn't something the steam client needs

And the "steam" process never eats more than 2GB of RAM. In fact it eats less because the UI has now been handed over to the WebHelper processes.

[cbogus]

Thanks for your responses, folks. I had hoped that someone from Valve staff would comment too, but yeah, maybe it's just a matter of (a long) time until this all changes. Oh well.

[Crazy Tiger]

Αναρτήθηκε αρχικά από cbogus:

Thanks for your responses, folks. I had hoped that someone from Valve staff would comment too, but yeah, maybe it's just a matter of (a long) time until this all changes. Oh well.

This is a user-to-user forum. Valve employees do not reply here.

[RiO]

Αναρτήθηκε αρχικά από Yujah:

I expect that the Steam client will turn 64-bit approximately a year from CEF dropping support for 32-bit. Which it'll probably not do for a long time still, and which is going to be irrelevant to OP's issue anyway, what with again it indeed being games that need the support.

The CEF parts of Steam are already 64-bit. On Windows this is easy to spot, because 32-bit processes are always suffixed with "(32-bit)" in Task Manager. Which the Steam Web Helper processes (which are the CEF parts) do not have.

Αναρτήθηκε αρχικά από thegreenpan:

I would prefer an X86 version as 64bit architecture only supports 64 bit software and 32bit architecture only supports 32bit software. X86 architecture supports both 32 bit and 64 bit software types. This is why there is a folder on C:\ called Program Files (x86) because programs in that folder use components of both 32bit architecture and 64 bit architecture to run.

Little history course:

X86 refers to the 80x86 instruction set.

This was originally a 16-bit instruction set for the 16-bit Intel 8086 CPU, built on the success of its 8080 8-bit CPU, which dove-tailed into the 80(0)86, 80186, 80286, 80386 and 80486. Or as the latter were more commonly referred to the 386 and 486. The 386 and 486 used a revised instruction set that was 32-bit (and should actually be referred to as IA-32 - i.e. "Intel Architecture, 32-bit"). This 32-bit instruction set remained backwards compatible with the old 16-bit instruction set and IA-32 "x86" CPUs could run both 32-bit and 16-bit code.

Intel later tried for a 64-bit architecture IA-64 with their Itanium processors, but this dead-ended. Instead the 64-bit gambit was won by AMD who extended the IA-32 "x86" instruction set to the x86-64 instruction set. A 64-bit version of the same instruction set with some additions thrown in, along with extensive compatibility modes that allowed the hardware to directly run 64-bit; 32-bit; and 16-bit code concurrently. Provided the operating system actually supports it.

Windows doesn't. As I've been told, that's because this was back in the WIntel-days and when Intel copied AMD's x86-64 it was a cheaply reverse-engineered knock-off that shoehorned the instruction set on top of Intel's existing hardware design philosophy and didn't allow concurrent use of 64-bit and 16-bit like AMD did; and which the Windows-Intel partnership didn't care about. (Or rather: Intel would've cared about to steal away AMD's advantage, I would presume.)

Colloquially x86 refers to the IA-32 version - i.e. a 32-bit Intel-compatible architecture; while "x64" refers to x86-64 - i.e. a 64-bit AMD-compatible architecture. This is also why it is sometimes referred to as "amd64", including by Microsoft in Windows - actually. If you trawl a 64-bit Windows installation's system folders you'll readily find packages labeled "amd64" in their naming.

-- end history lesson --


Moving, on:

The "Program Files (x86)" is called that then, because it is the designated default installation location for 32-bit programs. The actual 'emulation' that makes those 32-bit programs capable of talking to the OS APIs of a 64-bit Windows OS is in the SysWoW64 folder. ("SubSYStem for Windows (32-bit) On Windows 64-bit".)

Essentially just an API-wrapper / translation layer like the more well-known WINE is for Windows executables on Linux, albeit one directly and (almost) transparently integrated directly on the OS level.

The "Program Files (x86)" folder itself is not special and does not confer special emulation for 32-bit executables. You can dump those in any folder and they'll just run correctly, courtesy of SysWow64.

However if those programs are really old and rely on various quirks and legacy behavior of potentially deprecated Win32 APIs that wasn't actually beholden to any official specification, those programs may subtly break.
So the "Program Files (x86)" folder used to have some special casing applied for the behavior of various 32-bit APIs on certain edge-cases; making them behave the old way rather than the new way, etc. But most of that was dumped and is meant to be covered by the various legacy OS compatibility modes nowadays.

And it never had anything to do with the emulation of 32-bit code on 64-bit OS or using bits of both 32-bit and 64-bit OS-components. The latter simply isn't a thing. The OS has some 32-bit DLLs (all residing in SysWoW64) that 32-bit programs can dynamically load and execute, because obviously: a 32-bit process can't directly run 64-bit modules. It's either/or.
But those are part of that entire translation layer and still defer to the actual components that are 64-bit.

If you have some old 32-bit installers that wants to directly install into System32, then those are redirected to a quarantine folder in SysWoW64. Those actually would be real, 32-bit components. But again: they would be talking to the real 64-bit OS APIs via SysWoW64 translation.

Αναρτήθηκε αρχικά από Satoru:

Αναρτήθηκε αρχικά από lsdninja:

Did they say that before, or after, switching almost the entire client over to CEF and therefore requiring stupid amounts of RAM because Chrom(e,ium) leaks like a sieve? XD

Seriously though, it's mostly just the bootstrapper and a couple of other things that are still 32-bit and don't really need to be 64-bit. Linux users just complain the most because it's more visible when something is 32-bit. That said, the fact that Valve is making a 64-bit clean client on one platform (because it doesn't give them a choice) and none of the others is still laziness on their part.

The point is that 64bt main benefit is access to memory over 2GB. Which isn't that relevant for a client that basically never needs more than 2GB to do anything. Asking for 64-bit 'for the sake of it' isnt that relevant. You're not getting anything out of it. There's no performance benefit since again needing to address more than 2GB isn't something the steam client needs

There's actually a performance detriment if anything.
Because ironically x64 / x86-64 / amd64 architecture CPUs on average have better performance running software in 32-bit mode than they do in 64-bit mode.

There are very few real-world use cases where 64-bit offers genuine performance advantage and 32-bit doesn't outperform it. And the average video-game is not part of those use-cases.

Literally the only reason we 'need' 64-bit architecture video games is because of the stupid amount of addressable memory modern titles demand.

[davidb11]

Αναρτήθηκε αρχικά από cbogus:

Thanks for your responses, folks. I had hoped that someone from Valve staff would comment too, but yeah, maybe it's just a matter of (a long) time until this all changes. Oh well.

You are aware that Valve and stuff uses 64 bit, right?
I'm not sure where you got the idea it only uses 32 bit.

I mean, it works on Mac. :P Mac dropped support for 32 bit a long time ago.
And was the worst idea of all time. :P

Also, this is a user forum.
Why would you expect Valve staff to come here?

[cbogus]

Αναρτήθηκε αρχικά από davidb11:

You are aware that Valve and stuff uses 64 bit, right?
I'm not sure where you got the idea it only uses 32 bit.

Maybe you're trolling, and this thread is already dead, but this just happened here:

kernel: hl_linux[443468]: segfault at 90 ip 00000000cf37f132 sp 00000000cdc6c82c error 6 in libgdk-x11-2.0.so.0.2400.33[cf343000+6d000] likely on CPU 2 (core 0, socket 0)
[...]
  Module libX11.so.6 from rpm libX11-1.8.7-1.fc39.i386
  Module libGLX.so.0 from rpm libglvnd-1.7.0-1.fc39.i386
  Module libGL.so.1 from rpm libglvnd-1.7.0-1.fc39.i386
  Stack trace of thread 443468:
   #0  0x00000000cf37f132 gdk_display_open (libgdk-x11-2.0.so.0 + 0x50132)
   #1  0x00000000cf34c97e gdk_display_open_default_libgtk_only (libgdk-x11-2.0.so.0 + 0x1d97e)
   #2  0x00000000cef35c1e n/a (.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10 + 0x135c1e)
  ELF object binary architecture: Intel 80386

This summarizes this thread quite nicely: a 32 bit executable, 32 bit libraries all over the place, and shipping deprecated versions of it too: gdk_display_open_default_libgtk_only[docs.gtk.org] is deprecated since GTK 3.16, i.e. 2015. Steam is shipping old, deprecated stuff here, it's amazing that it works at all. Their 64 bit denial is just one (big) symptom of not giving a rat's ass about their fellow Linux users. Oh well.

[Crashed]

Αναρτήθηκε αρχικά από rawWwRrr:

Might be closer now that support for Windows 7/8/8.1 will be dropped. The number of 32-bit OS installs is getting nearer to zero. Not that Win10 doesn't also have 32-bit only support, but the chances that anyone is still using a 32-bit CPU requiring a 32-bit OS is nearly gone.

There are still numerous 32-bit Windows games and little sign of Microsoft deprecating WOW64.
Also this means that until Wine perfects their WOW64 thunks system Steam still needs 32-bit Linux libraries to run Proton.

Even with such a system in place the kernel may still require support for i386 binaries to some extent.

[davidb11]

Αναρτήθηκε αρχικά από cbogus:

Αναρτήθηκε αρχικά από davidb11:

You are aware that Valve and stuff uses 64 bit, right?
I'm not sure where you got the idea it only uses 32 bit.

Maybe you're trolling, and this thread is already dead, but this just happened here:

kernel: hl_linux[443468]: segfault at 90 ip 00000000cf37f132 sp 00000000cdc6c82c error 6 in libgdk-x11-2.0.so.0.2400.33[cf343000+6d000] likely on CPU 2 (core 0, socket 0)
[...]
  Module libX11.so.6 from rpm libX11-1.8.7-1.fc39.i386
  Module libGLX.so.0 from rpm libglvnd-1.7.0-1.fc39.i386
  Module libGL.so.1 from rpm libglvnd-1.7.0-1.fc39.i386
  Stack trace of thread 443468:
   #0  0x00000000cf37f132 gdk_display_open (libgdk-x11-2.0.so.0 + 0x50132)
   #1  0x00000000cf34c97e gdk_display_open_default_libgtk_only (libgdk-x11-2.0.so.0 + 0x1d97e)
   #2  0x00000000cef35c1e n/a (.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10 + 0x135c1e)
  ELF object binary architecture: Intel 80386

This summarizes this thread quite nicely: a 32 bit executable, 32 bit libraries all over the place, and shipping deprecated versions of it too: gdk_display_open_default_libgtk_only[docs.gtk.org] is deprecated since GTK 3.16, i.e. 2015. Steam is shipping old, deprecated stuff here, it's amazing that it works at all. Their 64 bit denial is just one (big) symptom of not giving a rat's ass about their fellow Linux users. Oh well.

That error has nothing to do with what I wrote.
LOL wut.

Steam is a 64 Bit app. Period.
Which means it uses 64 Bit memory limits.
THere are plenty of programs around that use 32 bit, but Steam is and has been for many many years been a 64 bit program.

[Crashed]

Αναρτήθηκε αρχικά από davidb11:

Αναρτήθηκε αρχικά από cbogus:

Maybe you're trolling, and this thread is already dead, but this just happened here:

kernel: hl_linux[443468]: segfault at 90 ip 00000000cf37f132 sp 00000000cdc6c82c error 6 in libgdk-x11-2.0.so.0.2400.33[cf343000+6d000] likely on CPU 2 (core 0, socket 0)
[...]
  Module libX11.so.6 from rpm libX11-1.8.7-1.fc39.i386
  Module libGLX.so.0 from rpm libglvnd-1.7.0-1.fc39.i386
  Module libGL.so.1 from rpm libglvnd-1.7.0-1.fc39.i386
  Stack trace of thread 443468:
   #0  0x00000000cf37f132 gdk_display_open (libgdk-x11-2.0.so.0 + 0x50132)
   #1  0x00000000cf34c97e gdk_display_open_default_libgtk_only (libgdk-x11-2.0.so.0 + 0x1d97e)
   #2  0x00000000cef35c1e n/a (.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10 + 0x135c1e)
  ELF object binary architecture: Intel 80386

This summarizes this thread quite nicely: a 32 bit executable, 32 bit libraries all over the place, and shipping deprecated versions of it too: gdk_display_open_default_libgtk_only[docs.gtk.org] is deprecated since GTK 3.16, i.e. 2015. Steam is shipping old, deprecated stuff here, it's amazing that it works at all. Their 64 bit denial is just one (big) symptom of not giving a rat's ass about their fellow Linux users. Oh well.

That error has nothing to do with what I wrote.
LOL wut.

Steam is a 64 Bit app. Period.
Which means it uses 64 Bit memory limits.
THere are plenty of programs around that use 32 bit, but Steam is and has been for many many years been a 64 bit program.

It would appear the Steam program is still 32-bit on Windows and Linux. And as I may have mentioned already this is likely by design to ensure compatibility with 32-bit games using Steamworks, Steam DRM Wrapper, or legacy Steam DRM.

[Satoru]

https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-267790879

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.

And again, the necessity for Steam to be 64-bit is mostly moot. There's no actual benefit to making it 64-bit. Nothing on the steam client needs this addtional RAM. And 32 bit is needed to support existing 32-bit games. So there's no pressing need to do this. Especially when there's a pretty well known performance detriment to doing so. And that steam still needs those 32 bit libraries to, again, support all the 32-bit games that are on Linux

I'm yet to hear of WHY this is necessary otehr than "I have an irrational fear of 32 bit libraries"

[Crashed]

Αναρτήθηκε αρχικά από Satoru:

https://github.com/ValveSoftware/steam-for-linux/issues/179#issuecomment-267790879

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.

And again, the necessity for Steam to be 64-bit is mostly moot. There's no actual benefit to making it 64-bit. Nothing on the steam client needs this addtional RAM. And 32 bit is needed to support existing 32-bit games. So there's no pressing need to do this. Especially when there's a pretty well known performance detriment to doing so. And that steam still needs those 32 bit libraries to, again, support all the 32-bit games that are on Linux

I'm yet to hear of WHY this is necessary otehr than "I have an irrational fear of 32 bit libraries"

On Windows, 32-bit libraries are still mandatory to be installed (with the exception of Server Core which isn't intended to be used in GUI mode) and even many of your 64-bit drivers like graphics drivers include 32-bit libraries for compatibility (surprised the bloat of NVIDIA drivers hasn't exhausted memory space for such games).
On Linux however, 32-bit libraries are optional and some may not be pleased with having to install them on their distros just to run Steam.

[Satoru]

Αναρτήθηκε αρχικά από Crashed:

On Windows, 32-bit libraries are still mandatory to be installed (with the exception of Server Core which isn't intended to be used in GUI mode) and even many of your 64-bit drivers like graphics drivers include 32-bit libraries for compatibility (surprised the bloat of NVIDIA drivers hasn't exhausted memory space for such games).
On Linux however, 32-bit libraries are optional and some may not be pleased with having to install them on their distros just to run Steam.

Why Linux users are somehow trying to speed run "Apple has the best software model" is just amusing to no end.