Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
0 
Report this post
Some Linux distributions and SteamOS don't have that issue. Ubuntu allows running 32 bit apps under 64 bit OS as of here: https://askubuntu.com/questions/454253/how-to-run-32-bit-app-in-ubuntu-64-bit
SteamOS on Steam Deck should be able to handle it appropriately without user input.
Apple owns the Mac ecosystem and have a lit of control. MS only owns Windiws, not PC.
PC thrives on legacy support. So it's a bit harder to just do what Apple did.
So how about "no". Especially since "as far as I know" shows you know little.
Couldn't you convert both to one app and add a 32bit package query so there is less maintenance for Mac? If then 64 bit only Windows comes, which I don't think will happen in the future (except maybe Windows core OS) then the client would already be compatible 🤔 before Steam wants to use the packages it first asks which system and if 32bit support is installed, and only then needs the packages if they are installed.
But programming this first also takes time, of course.
Of course the 32bit games should continue to run, but as far as I know there is currently no Proton version that can translate the graphics. But then we would at least have one less problem to work on (Steam client) and then you can't go to 64 bit only because of Proton.
The problem could be solved by integrating one part into Mesa and the other part into Proton. So that 32bit games run on 64bit only systems.
Some other 32bit software also runs on 64bit only systems thanks to wine WoW 64, but not everything.
The reason for this is the maintenance effort
Also going to 64 Bit won't magically make everything better. There are programs that just do not get any benefit from it.
Sure, I'm still against removing 32bit support from Linux, but if Proton and Wine WOW 64 are so good that it supports 32bit Windows games + programs without the 32bit support in the system, then I'm in favor of removing support for 32bit applications.
Shouldn't Steam be made available to all? With or without 32bit support? With Linux you currently have to run Steam in a VM or similar with 32bit support with a lot of effort on systems without 32 bit packages and can download the 64 bit games and then / must start them in the system without Steam (not in the VM or similar).
Why so complicated?
Steam is available to all. There is no advantage for Steam to abolish 32bit support or become 64bit only.
This is a function which takes a floating-point number, adds it to a constant, and returns the result. In 64-bit mode, that compiles to:
'addss' is an instruction which takes the value in the xmm0 register (a register being the very very fastest kind of memory, directly part of the core of the CPU itself), adds it to the value at the memory location '.LC0' (which is the constant we specified before) and puts the result into the xmm0 register.
The '[rip]' in .LC0[rip] means that the address is stored as the offset between the 'addss' instruction and .LC0, so this will work without modification wherever this code happens to be loaded in memory. (rip stands for "instruction pointer register", and it's a register which stores the address of the currently executing instruction. If you know that another instruction or data is x bytes away from the current instruction, then you can calculate the absolute address as rip + x).
The values are stored in xmm0 as that's the 'calling convention' for this kind of function in x86_64. The first floating-point parameter to a function is stored in xmm0, and a floating-point return value from a function is stored in xmm0.
'ret' returns to the function which called this one.
In x86 mode, the function compiles to:
Yikes. x86 doesn't support addressing relative to rip, so you need a bunch of extra boilerplate to calculate the address of the constant using something called the global offset table (GOT).
Once the address is calculated, it needs a whole instruction (fld) to load the constant. Then when we get to the add (fadd), the parameter, the number we want to add to the constant isn't in a register. It's on the stack, i.e., in main memory, which is much slower to access than a register. It's loaded from an offset of 4 from the stack pointer (esp). We have to load the parameter value from slow memory rather than it being stored in a fast register because x86 just doesn't have as many registers available as x86_64.
AMD used the opportunity afforded by x86_64 being a new ABI to fix many of the inefficiencies of x86 by adding rip-relative addressing, and using the extra general-purpose registers introduced to improve the efficiency of passing parameters to functions.
And that's not to mention other improvements afforded by 64-bit, like the security mitigation ASLR being more effective because you can get more randomness out of the larger address space. But this post is getting long enough already.
For completeness: there are some slight downsides to 64-bit too. If your code uses data structures with a lot of pointers, the structures won't be as dense in memory as with 32-bit pointers, so fewer structures will fit into L1 cache, meaning that cache misses are more likely, which is bad for performance. Linux tried to introduce an x32 ABI which used 32-bit pointers while still keeping the other benefits of x64 to get the best of both worlds, but it's mostly fallen out of use as not really worth it.