News Steam and Linux gaming is safe: Fedora will not drop 32-bit support after all — dev says proposal was 'not some conspiracy to break the gaming use...

[Admin]

The developers behind Fedora have withdrawn their proposal to drop 32-bit support from the OS. Fedora 44 will maintain 32-bit support, allowing Steam to keep functioning on the Linux distribution.

Steam and Linux gaming is safe: Fedora will not drop 32-bit support after all — dev says proposal was 'not some conspiracy to break the gaming use... : Read more

 

[usertests]

 

[eye4bear]

The developers behind Fedora have withdrawn their proposal to drop 32-bit support from the OS. Fedora 44 will maintain 32-bit support, allowing Steam to keep functioning on the Linux distribution.

Steam and Linux gaming is safe: Fedora will not drop 32-bit support after all — dev says proposal was 'not some conspiracy to break the gaming use... : Read more

I read about all the hate towards Fedora, but I didn't see anything aimed at Steam for not working on updating their software.

 

[ezst036]

I read about all the hate towards Fedora, but I didn't see anything aimed at Steam for not working on updating their software.

I was thinking the same thing. Because Valve got pwned by Apple, we know based on evidence that Valve has a 64-bit Steam client and its released into the wild.

Why is Valve holding this Steam client back from being released (on Windows? and) on Linux? Valve usually gets a lot of things right and I'm happy to toot the horn about Valve's awesomeness but on this one they are really dropping the ball and letting all of us down.

Fedora doesn't deserve all the heat they've taken on this.

 

[palladin9479]

I was thinking the same thing. Because Valve got pwned by Apple, we know based on evidence that Valve has a 64-bit Steam client and its released into the wild.

Why is Valve holding this Steam client back from being released (on Windows? and) on Linux? Valve usually gets a lot of things right and I'm happy to toot the horn about Valve's awesomeness but on this one they are really dropping the ball and letting all of us down.

Fedora doesn't deserve all the heat they've taken on this.

That's not what is going on.

Steam binaries are already 64-bit. Not all games on steam are 64-bit, especially those without native Linux versions. 32-bit code requires 32-bit libraries and abstraction layers. Wine has two sets of binaries / libraries, the 64-bit version for 64 bit NT applications and the 32-bit version for 32-bit NT applications. Removing 32-bit support from the OS effectively disables those 32-bit applications and makes playing NT games on Linux very difficult. This is especially true for games that come with launchers or config tools, those are usually 32-bit while the game binary itself will be 64-bit.

 

[ravewulf]

He's severely out of touch if he didn't expect the backlash he got. Moving open-source software to 64-bit is all well and good if you put in the effort but there will always be legacy 32-bit closed-source software that people want to run.

 

[ezst036]

That's not what is going on.

Steam binaries are already 64-bit. Not all games on steam are 64-bit, especially those without native Linux versions. 32-bit code requires 32-bit libraries and abstraction layers. Wine has two sets of binaries / libraries, the 64-bit version for 64 bit NT applications and the 32-bit version for 32-bit NT applications. Removing 32-bit support from the OS effectively disables those 32-bit applications and makes playing NT games on Linux very difficult. This is especially true for games that come with launchers or config tools, those are usually 32-bit while the game binary itself will be 64-bit.

I was generally responding to the previous comment. However at least on Linux, Steam itself is known not to be 64 bit as of somewhat recently. I've never seen more recent info as to if/when that changed: (it could be 64 by now)

https://github.com/ValveSoftware/steam-for-linux/issues/10318

I appreciate and understand the rest of the comment about libraries, it is a good summary. This is all related to WINE WoW64, which I think Arch may have upstreamed a few days ago.

View: https://www.youtube.com/watch?v=BKB_OT593vs

 

[palladin9479]

I was generally responding to the previous comment. However at least on Linux, Steam itself is known not to be 64 bit as of somewhat recently. I've never seen more recent info as to if/when that changed: (it could be 64 by now)

https://github.com/ValveSoftware/steam-for-linux/issues/10318

I appreciate and understand the rest of the comment about libraries, it is a good summary. This is all related to WINE WoW64, which I think Arch may have upstreamed a few days ago.

View: https://www.youtube.com/watch?v=BKB_OT593vs

Steam has multiple components. The launcher gui is either 32-bit or 64-bit depending on OS, they just pick whatever target they want on compile time as it supports both. The steamwebhelper launches as whatever your OS supports is a custom web browser, basically the store, forums and everything not launching games.

That's all trivial though as Valve already has 64 bit support. The issue has always been support for 32-bit libraries. Syswow64 isn't arch specific and has nothing to do with linux. It's NT's way of managing multiple 32-bit libraries on a 64-bit native OS. Take somethings like d3d9.dll, inside system32 there will be the 64-bit native binary, but that is unusable to 32-bit executables. Instead when a 32-bit executable goes to call it, syswow64 redirects it to one of the 32-bit versions it holds.

Wine64 has supported this for awhile and in fact I have a 64-bit prefix setup right now for a game that uses a 32-bit launcher to start a 64-bit executable. The 32-bit libraries still require 32-bit kernel support and abstraction layer. 32-bit code absolutely can not run on a CPU in 64-bit exclusive long mode. Instead 32-bit code must run inside a submode called compatibility mode. All those 32 bit OS libraries are there to ensure code inside that compatibility mode doesn't attempt to exit and run in long mode resulting in process exceptions.