Apple chose to drop support for 32-bit applications in macOS 10.15 (released 2019), and since many developers have not updated their games to support 64-bit executables, some games will effectively stop functioning on macOS.
This change is required as core features in Steam rely on an embedded version of Google Chrome, which no longer functions on older versions of macOS.
Hmmmm.
It would be interesting to see a list of which games are affected.
Some games (at least on Linux, that I’ve seen, and I would assume on MacOS) that are distributed on Steam don’t actually require Steam to be present to run. Like, Caves of Qud will work fine without Steam present; they just use it to distribute and update the binaries, not for any kind of DRM or anything. So for those guys, as long as you can download the binaries via Steam (or a related app…I remember that there’s some Python program that can download from Steam using credentials) you can presumably copy them to a 32-bit guest VM.
Some games will probably actually rely on Steam, like for achievements or something. For those…If there are a substantial number of Mac games that won’t work in a 64-bit environment, I am wondering if it is possible to make a “steamlib proxy” – basically, have a 32-Mac VM, run the game in a VM, but have Steam running in a 64-bit host environment, and just relay calls to a process launched under the host environment that uses the host steamlib to talk to Steam. Valve presumably isn’t gonna set that up as a supported environment, but I wonder if that might be a viable open-source project.
EDIT: Not the Python program I was thinking of, but here’s a .NET program that downloads apps from the depots, just to demonstrate that it’s an option.
Some games will probably actually rely on Steam, like for achievements or something. For those…If there are a substantial number of Mac games that won’t work in a 64-bit environment, I am wondering if it is possible to make a “steamlib proxy” – basically, have a 32-Mac VM, run the game in a VM, but have Steam running in a 64-bit host environment, and just relay calls to a process launched under the host environment that uses the host steamlib to talk to Steam. Valve presumably isn’t gonna set that up as a supported environment, but I wonder if that might be a viable open-source project.
I think Proton has something of that nature, so games running inside Wine talk to the native Linux Steam binary.
WINE doesn’t really isolate apps. Valve may have done some degree of compatibility work or not for the Windows Steam library, but the game running under WINE doesn’t have any real restrictions on its ability to talk to Linux software. As long as the Steam Windows library and the Linux Steam client use some form of IPC mechanism that works on both platforms, like TCP sockets, it should “just work”, same way a Windows web browser running in WINE would “just work” when talking to a Linux webserver on the same machine.
But if someone’s having to set up a 32-bit VM running a different MacOS guest OS, then they’re not gonna be able to run Steam in the guest (due to the Chrome requirements that Valve mentioned), and I don’t believe that programs using the Steam library can talk to Steam on another host normally.
I’m just saying the “steamlib proxy” concept you mentioned is not only possible but has at least one implementation. The fact that Wine isn’t true isolation doesn’t really change anything (maybe other than the exact details of the underlying IPC channel, which could use some kind of optimized shared memory magic) unless I’m misunderstanding something.
Hmmmm.
It would be interesting to see a list of which games are affected.
Some games (at least on Linux, that I’ve seen, and I would assume on MacOS) that are distributed on Steam don’t actually require Steam to be present to run. Like, Caves of Qud will work fine without Steam present; they just use it to distribute and update the binaries, not for any kind of DRM or anything. So for those guys, as long as you can download the binaries via Steam (or a related app…I remember that there’s some Python program that can download from Steam using credentials) you can presumably copy them to a 32-bit guest VM.
Some games will probably actually rely on Steam, like for achievements or something. For those…If there are a substantial number of Mac games that won’t work in a 64-bit environment, I am wondering if it is possible to make a “steamlib proxy” – basically, have a 32-Mac VM, run the game in a VM, but have Steam running in a 64-bit host environment, and just relay calls to a process launched under the host environment that uses the host steamlib to talk to Steam. Valve presumably isn’t gonna set that up as a supported environment, but I wonder if that might be a viable open-source project.
EDIT: Not the Python program I was thinking of, but here’s a .NET program that downloads apps from the depots, just to demonstrate that it’s an option.
Mac OS itself won’t run 32 bits apps since 10.15 (released in 2019).
Sure, you’d need to run an old version of MacOS in the VM.
I think Proton has something of that nature, so games running inside Wine talk to the native Linux Steam binary.
WINE doesn’t really isolate apps. Valve may have done some degree of compatibility work or not for the Windows Steam library, but the game running under WINE doesn’t have any real restrictions on its ability to talk to Linux software. As long as the Steam Windows library and the Linux Steam client use some form of IPC mechanism that works on both platforms, like TCP sockets, it should “just work”, same way a Windows web browser running in WINE would “just work” when talking to a Linux webserver on the same machine.
But if someone’s having to set up a 32-bit VM running a different MacOS guest OS, then they’re not gonna be able to run Steam in the guest (due to the Chrome requirements that Valve mentioned), and I don’t believe that programs using the Steam library can talk to Steam on another host normally.
I’m just saying the “steamlib proxy” concept you mentioned is not only possible but has at least one implementation. The fact that Wine isn’t true isolation doesn’t really change anything (maybe other than the exact details of the underlying IPC channel, which could use some kind of optimized shared memory magic) unless I’m misunderstanding something.