Steam Drops macOS Mojave Support, Effectively Ending Life For Many 32-Bit Games (arstechnica.com) 71
An anonymous reader quotes a report from Ars Technica: Valve Software's Steam gaming marketplace and app will drop support for macOS 10.13 (High Sierra) and 10.14 (Mojave), according to a support page post. The change will go into effect on February 15, 2024. What will happen exactly? Valve writes: "After that date, existing Steam Client installations on these operating systems will no longer receive updates of any kind including security updates. Steam Support will be unable to offer users technical support for issues related to the old operating systems, and Steam will be unable to guarantee continued functionality of Steam on the unsupported operating system versions."
"The Steam store will stop considering games that offer only 32-bit macOS binaries to be Mac compatible at the end of 2023," Valve writes. The post also notes that fewer than two percent of current Mac users on Steam are running macOS 10.14 or earlier, so this only affects the small number who are holding on to those older versions that supported 32-bit apps. To be clear, lack of support for macOS 10.14 doesn't necessarily mean Steam won't run at all on machines running that OS. It just means Valve won't guarantee it'll work, and won't lift a finger to help if something breaks in the passage of time. It also means users who continue to use the older software could become vulnerable to security risks, disincentivizing continued use.
"The Steam store will stop considering games that offer only 32-bit macOS binaries to be Mac compatible at the end of 2023," Valve writes. The post also notes that fewer than two percent of current Mac users on Steam are running macOS 10.14 or earlier, so this only affects the small number who are holding on to those older versions that supported 32-bit apps. To be clear, lack of support for macOS 10.14 doesn't necessarily mean Steam won't run at all on machines running that OS. It just means Valve won't guarantee it'll work, and won't lift a finger to help if something breaks in the passage of time. It also means users who continue to use the older software could become vulnerable to security risks, disincentivizing continued use.
They will still works, just no updates (Score:3)
Re:They will still works, just no updates (Score:4, Interesting)
What I didn't see mentioned is what happens if your storage fails and you rebuild the machine. Will you be able to download a copy of the old compatible-with-my-ancient-hardware Steam client, that will still be able to connect to Steam and download games? How about 10 years from now?
What if nobody's connected with one of those machines for a decade and then some tech history enthusiast pulls their old system out of storage and tries to reload their old games that they 'bought'?
Sure, edge cases, but right is right. If you bought those games, Steam should be planning to make archival clients available and functional - at least for the games of their era - for extremely long periods of time. That or ship local install media to people with discontinued platforms.
Re: (Score:3, Funny)
I am happy they only drop support for 32 bit games so my 16 bit games should keep working!
Re: (Score:2)
Somebody +1 this. :)
Re:They will still works, just no updates (Score:4, Informative)
Of course the 16-bit games will keep working. Thanks to Dosbox.
Re:They will still works, just no updates (Score:5, Insightful)
Re: (Score:3, Insightful)
What I didn't see mentioned is what happens if your storage fails and you rebuild the machine.
If you don't have a backup should not expect anything to run as before. This isn't a Steam issue, it's a management of your hardware issue.
Re: (Score:2)
I don't backup data that I can reinstall. It's a waste of backup resources.
Re: They will still works, just no updates (Score:2)
I agree on that, but I think that's the whole crux of what they were getting at... They were asking if it would even be *possible* to reinstall them once valve has deprecated support, since TFS mentions valve will be removing 32-bit only mac games from their compatibility list. If that is the case, it *absolutely* is something that you can't reinstall.
However, I use Linux as my daily driver, including playing games on steam, so I can put my experience here.
I use valve's official steam client for my OS. No
Re: (Score:2)
I don't backup data that I can reinstall. It's a waste of backup resources.
And that is why your backup solution is failing to provide you a system as it was working beforehand. You should backup anything that you want to keep as before, and that especially includes software which is out of support on your target system.
All the data in the world is useless if you can't run a program to read it.
Re: (Score:2)
Nah, I'll just install the software I want as needed again and have it load my user data and save games from the backup. If I had to backup TB of games then I would spend a lot more on useless backups
Re: (Score:2)
If your storage fails and you rebuild one of these machines, you're necessarily moving from an Intel Mac that supports 32-bit x86 executables to an Apple Silicon Mac that is 64-bit only. Neither of these macOS versions support Apple Silicon.
It's the Apple equivalent of "move fast and break things".
Re: (Score:2)
Re: (Score:2)
I'm not doing games on MacOS, but I most certainly play older games regulalry. Meaning 32-bit support is important, even in Steam. Even some 16-bit games on occasion. It's a big enough market that there are onlines stores specializing in older games as well.
Re: (Score:2)
For now. Eventually Steam will fail to log in after some new update. That's what happened with previous versions as well. At least not without some nasty hacks. There were hacks available to get older Steam versions from older OSes to log in but who knows if they work anymore.
But in general I agree. If you insist on connecting to the internet you shouldn't be using old outdated crap. The world shouldn't need to support or tolerate you, and if you're offline you don't care about this announcement anyway.
Also
Re: (Score:1)
Not a Mac user (Score:2)
I don't use Mac, but don't later MacOS versions not support 32 bit games anyway? Or is that just M* based machines?
Re:Not a Mac user (Score:4, Informative)
Re: (Score:2)
Yeah, it is - especially given that so many of those developers went out of business years ago. So it's the 32-bit version, or nothing.
Re: (Score:2)
Re: (Score:2)
I actually do the same thing. It covers 90+% of the old games I play... there are just a handful of Mac-only games that got left behind.
It may not be perfect, but it's surprisingly good. And kudos to Codeweavers for doing what Apple couldn't! (or wouldn't)
Re: (Score:2)
It may not be perfect, but it's surprisingly good. And kudos to Codeweavers for doing what Apple couldn't! (or wouldn't)
Agreed on all points
Re: (Score:2)
I doubt it's "couldn't" and very much "wouldn't". I'm sure they will drop 64-bit Intel support at some point, and companies Valve will have to decide how long they want to support a dwindling customer base on aging hardware.
Re: (Score:2)
Apple as a policy doesn't support 32-bit binaries anymore.
Crossover does some magic to run 32-bit applications in a 64-bit address space.
Re: (Score:2)
Agreed, I'd recommend Crossover. It's not that expensive, very easy to use, extensively documented, and buying it supports Wine development.
Sure it has quirks. For example, L4D2 is unplayable when a chapter loads, but works fine if you leave it a little while to finish loaded assets. I'm happily running my old games on an M1,.
Re: (Score:2)
If you're on an Intel Mac, is a VM also an option?
Re: (Score:2)
Not if the game is graphically intensive. You don't get GPU passthru on MacOS. The OS doesn't implement the necessary functionality. If it has primitive graphics then it might work in Parallels.
Linux has rapidly become the best gaming OS. Many games run properly on Linux using Proton (or Proton-GE) and you can have GPU passthrough with KVM so you don't have to install Windows on the metal but can still have good graphics performance. This does require either an additional GPU or that you drop out of the GUI
Re: (Score:2)
Maybe I'm wrong, but I was thinking that 32-bit games on a Mac must old thus not very demanding. VMWare Fusion does support various degrees of graphical hardware acceleration, but I couldn't tell you if it's enough.
Re: (Score:2)
I haven't messed with virtualization on a mac since I got out of Apple land too early for it to be of any use to me, but with vmware player (which I've had pretty good luck with) on windows or linux it's hit and miss which games will work properly. The only one I've had much success with is DXVK on Proton, but Apple doesn't support Vulkan so it won't help you on Mac OS.
Metal really is a big problem. I know Vulkan didn't exist when Apple released it, but just like the Type C connector in relation to the Ligh
Re: (Score:2)
What actually makes Vulcan better than Metal though?
That's a serious question, not famboyism, me not being a graphics API expert. The thing is, I see bashing of Metal and praise of Vulcan all the time. But when I do, it's pretty much always been based on ideological purity, not technological superiority. No one ever seems to do a breakdown of the feautres and differences between the two and detail exactly how and why Vulcan is supposed to be superior besides, "Derrr herrr... Metal was made by crApple, so
Re: (Score:1)
I'm not either but I've read a bit about it here and there as this has kept coming up and I like to stay informed, and Metal is more restricted and does more handholding while Vulkan allows closer access to the hardware. The place for the specialization is in the engine, not in the API, which has to be able to provide full access not only to current hardware but also what exists in the future.
Or in short, you can get better performance with Vulkan, and it's easier to use Metal. They could reimplement Metal
Re: (Score:2)
Well, there's always the Windows VM option. But make sure you archive the games instead of relying on Valve to do this for you. Then you can even keep an old Windows version that runs everything old just fine.
Remember back when Apple had dual binaries, for having both PowerPC and Intel? 32 + 64 bit support is even easier.
Re: (Score:3, Interesting)
Supporting multiple memory unit sizes is a very complex thing that most of us take for granted. (Disclaimer: my knowledge here isn't perfect -- this is something I just started hacking at a few weeks ago.)
You can't arbitrarily mix binary code that makes different assumptions about memory unit widths (mainly pointer lengths) into the same memory space without setting yourself up for failure. And even if you somehow could, it would be incredibly error prone given the assumptions that compilers make about the
Re:Not a Mac user (Score:5, Insightful)
You can't arbitrarily mix binary code that makes different assumptions about memory unit widths (mainly pointer lengths) into the same memory space without setting yourself up for failure.
Well, no sh!t, Sherlock. Thankfully, the big boys use other, safe and fully supported ways to mix 32-bit and 64-bit :) And when I say "big boys" it's actually everyone but the "differently thinking" Apple.
Likewise, when you have a 64-bit kernel running against the metal, the 32-bit code has to be wrapped or otherwise adapted somehow to align with the kernel hooks from within its VMA space.
Sounds difficult and dangerous... yet 64-bit Windows runs 32-bit binaries perfectly fine... same with Linux and others.
your operating system needs a full set of OS binaries for each width you intend to support
Not a problem, with the modern multi-gigabyte OSes. Even Linux does that, without being too bloated.
Running 8-bit on 16-bit was never a thing in the PC world as far as I'm aware. You were either on 8-bit CP/M with an 8080, or 16-bit DOS (or 16-bit CP/M) with an 8086 and up.
This is a rather confusing statement. One could say that Intel 8088 was an 8-bit CPU, and some x86 instructions like "mov AL, BH" seem quite 8-bit (because it moves 8 bits from one register to another). You could just say that the x86 architecture started with the i8088 and i8086 CPUs, and that any earlier CPUs, including i8080, weren't x86 compatible, so of course one couldn't run 8-bit 8080 code on 8/16 bit 8088.
Also, just to clarify, there are (were) other OSes than CP/M for i8080 and other OSes than DOS and CP/M 86 for the i8086.
Though we pretty much stopped using 16-bit x86 entirely once UEFI ruled the PC world.
You mean, only UEFI is stopping folks from running DOS and Windows 3.1 on a bare metal? This is ridiculous. Not to mention that virtualization exists. As regards DOS and Windows 3.1 applications, they were killed by 64-bit Windows AND obsolescence.
Some old [slashdot.org] farts [slashdot.org] are still using a CSM and still think it's BIOS, but that's about it.)
Not gonna comment about the "old farts", but UEFI+CSM IS a BIOS. If something looks like a duck and quacks like a duck...
Anyways, it simplifies the shit out of things if your OS can drop support for anything and everything smaller than whatever your kernel uses.
Anyway, Apple just loves dropping support for things.
C++ developers are all old and cranky geezers
Oh boy.
deep down they knew all along that their language of choice was a pointless leap backwards from whence it came.
Facepalm.
(Though I'm not sure what that article means by real-mode being obligatory, as Intel says [intel.com] you can switch directly into flat protected mode.)
Real mode is obligatory because according to the current x86 specification, the CPU starts in a "hacked" real mode (hacked means made able to access another window of memory instead of the first megabyte), and runs some real mode code to bootstrap protected mode, 64-bit long mode or whatever is needed by the boot loader. If you change the specification, then and only then you can do without real mode.
Re: Not a Mac user (Score:2)
Well, no sh!t, Sherlock.
Wasn't talking to you, Watson.
Sounds difficult and dangerous... yet 64-bit Windows runs 32-bit binaries perfectly fine... same with Linux and others.
That's the point.
You mean, only UEFI is stopping folks from running DOS and Windows 3.1 on a bare metal? This is ridiculous. Not to mention that virtualization exists. As regards DOS and Windows 3.1 applications, they were killed by 64-bit Windows AND obsolescence.
It doesn't sound like you understand what is meant by bare metal. Otherwise why bring up virtualization?
Not gonna comment about the "old farts", but UEFI+CSM IS a BIOS. If something looks like a duck and quacks like a duck...
Except it doesn't. It's UEFI. The E stands for extensible. To put it in terms your generation might understand, loading a CSM doesn't cause every other module to disappear into a Scooby Doo mystery, nor does it mean that the UEFI has to do everything that BIOS did. For example, you can still boot directly to GPT with it loaded. BIOS can't do that at all, amon
Re: (Score:2)
Well, yeah, it can be done, but it raises costs, complexity, and generates a lot more heat, and hurts performance. Apple's approach to dump it and emulate 32 bit is better IMO. It'll hurt in the short term, but not as much as you would think due to the performance gains.
Re: (Score:3)
It's interesting though that macOS used to be able to run 64-bit applications on a 32-bit kernel. None of the obvious shenanigans that you mentioned (WoW64) that you have to be aware of on Windows that impact file and registry locations, although of course, Microsoft never supported this configuration anyway.
Re: Not a Mac user (Score:2)
You'd still need separate 64-bit libraries, basically the opposite of wow64. This would be really pointless otherwise.
Re: (Score:2)
Mojave v10.14 is the last one to support 32-bit. :(
Re: (Score:2)
Aren't machines in the M1-M2 series fast enough to emulate 32 bit apps?
Awesome. Mac Half Life works for three months (Score:2, Funny)
Awesome. The 25th anniversary edition of Half Life [slashdot.org] for the Mac will last for exactly 90 days between the announcement date on November 17 and the date when Steam drops support for the last remaining Macs that can still run it.
Yay!
Re: (Score:2, Informative)
There appears to be a 64 bit osx binary. Is this somehow mislabeled?
For the record, it isn't steam dropping 32 bit support on macs, it was apple that dropped it. They will be dropping x64 at some point too.
Not saying this is right or wrong, but it wasn't steam that stopped selling 32 bit macs or stopped releasing xcode able to target them.
I'm honestly shocked valve was even able to compile and release a 32 bit version tbh.
It's not like valve or most any company releases 32 bit binaries for anything at all
Re: (Score:2)
There appears to be a 64 bit osx binary. Is this somehow mislabeled?
It might have a 64-bit binary on Windows, but there's not one for macOS. The page for the game says "Your current macOS version is unable to run 32-bit games. This game may not run." When I download it and look inside the installed binaries, the Mac binaries are entirely i386 architecture.
I'm honestly shocked valve was even able to compile and release a 32 bit version tbh.
Me, too. It is built against the 10.7 SDK, which means they must have used a Mac running Catalina (or older) from 2019 and Xcode 12 (or older) from 2020 just to build it at all. The only thing more surprising than them
Re: (Score:2)
It's not particularly hard building for 10.7: Mac Minis last a long time, and older versions of macOS can be virtualise. I think we were creating 10.7 compatible builds on macOS 10.12.
However, the question really is: why? How many 10.7 users are still out there? I have a late 2007 MacBook Pro that I still use, and it's running 10.11. This machine is old and slow though, although sufficient for email, some browsing, MS Office. My wife didn't even complain about the performance creating a Snapfish photo
Re: (Score:2)
It might have a 64-bit binary on Windows, but there's not one for macOS. The page for the game says "Your current macOS version is unable to run 32-bit games. This game may not run." When I download it and look inside the installed binaries, the Mac binaries are entirely i386 architecture.
For whatever reason Steam displays a warning about 32-bit binaries for most of the 64-bit mac compatible games I have, so I too installed Half-Life just to check and can confirm that for once the 32-bit warning is actually accurate. Shame.
Re: (Score:2)
The only thing more surprising than them managing to build it is the fact that they bothered to built it in the first place, given that they had to have known by that time that just two weeks after the announcement, they'd be announcing that they're about to drop support for 32-bit Mac games....
I have my issues with it, but it's still true that Valve is the most responsible of app store companies. They put that update out there for the people who will continue to keep an old Mac for gaming. They can not make those games work on more recent MacOS because of Apple, it's not their fault. They're doing what they can for their customers who were dumb enough to think that continuing to give Apple money when they have shown themselves to be consumer-hostile over and over again through the years was a goo
Re: (Score:2)
The only thing more surprising than them managing to build it is the fact that they bothered to built it in the first place, given that they had to have known by that time that just two weeks after the announcement, they'd be announcing that they're about to drop support for 32-bit Mac games....
I have my issues with it, but it's still true that Valve is the most responsible of app store companies. They put that update out there for the people who will continue to keep an old Mac for gaming. They can not make those games work on more recent MacOS because of Apple, it's not their fault.
I actually dug into the output of nm and found that it is built using the Carbon API. Although that wasn't formally deprecated way back in 2012, but wasn't the recommended way to write new apps since Mac OS X (2001). Basically, this continued to run up until about five years ago because 22 years ago, Valve did exactly the absolute minimum amount of work to make a Mac OS 9 app keep running on Mac OS X, and then did the absolute minimum amount of work again to make it run on 32-bit Intel a few years later (
Re: (Score:2)
I have to disagree about the touchbar itself. It was a neat and, in the few cases where it was adequately supported, fairly useful concept. The majority of the F-keys were never really useful except for the alternate volume/brightness/etc controls anyway. And it's not really Apple's fault that so many app developers were so lacksadasical about actually using it.
The real screwup with the touchbar was the lack of a physical Escape key (A whole lot more useful and needed than any F-key.) on the early models
Re: (Score:1)
Running Windows apps from the Windows 98 era require virtualization, too, typically.
I hear they're deprecating x32 support now too. So much for Windows being the bastion of backwards compatibility. Now there is only Linux. It wasn't worth putting Linux on a B&W G3 though. Much easier and cheaper to just give up on Apple.
so this only really affected users who wanted to replace their internal ATA drive with a larger, newer drive and boot from it.
Yes, Apple getting in the way of users upgrading their own storage is still a problem too. They are insufferable. If I buy it it's my machine, not theirs.
Re: (Score:2)
It's not like valve or most any company releases 32 bit binaries for anything at all anymore, seeing windows doesn't support it
Windows doesn't support 32-bit binaries? Since when?
Re: (Score:2)
Windows 11 dropped support for mixed 16-bit/32-bit binaries, but I don't think those worked on 64-bit installs of Windows anyway, so nothing really changed unless you were running 32-bit Windows 10 and wiped your boot drive to install 64-bit Windows 11.
32-bit binaries are handled by WOW64, which AFAIK has not been dropped.
Maybe you're thinking about the update where they are planning to drop support for 32-bit ARM binaries?
Re: Awesome. Mac Half Life works for three months (Score:2)
64-bit windows never included NTVDM, which is required for 16-bit binaries to run at all. They dropped it because for it to work they basically had to rewrite part of it for it to run under the 64-bit kernel, which they felt wasn't worth it. They kept it for 32-bit windows until there was no more 32-bit windows.
Re: (Score:2)
You get what you pay for, which was ... *checks notes* ... $0.
Re:Proprietary software (Score:4, Insightful)
None of which has anything to do with anything - you have all the permission in the world to keep using your software, even the summary tells you that.
The problem is that you can't UPGRADE that software, port it, recompile it, or even fix bugs in it.
Copyright here has absolutely no influence, mostly because Steam doesn't even hold the copyright either!
The problem here is suppliers abandoning software, failing to patch software, refusing to port software, and not even bothering to give their customers an avenue to do that themselves.
Your argument for "copyright" is actually an argument for "open source", stable APIs, emulation and compatibility layers (remember that new Macs are not even x86!), backwards compatibility and releasing source to abandoned intellectual properties. Most of which are utterly dependent on copyright existing and working.
Re: (Score:2)
I'm not a fan of copyright but I also think it's easy to claim the idea is entirely problematic when there isn't really a way to know when can't tell what things would be like without it. I'll focus o
Re: (Score:2)
The problem here is suppliers abandoning software, failing to patch software, refusing to port software, and not even bothering to give their customers an avenue to do that themselves.
You can't honestly expect a company to support a platform in perpetuity. Steam dropped support for Windows 7/8 a while ago to little fanfare. Both OS's are no longer supported by Microsoft. As a gamer (since the 1980s) I know it's important to keep my HW and operating systems up to date, not to mention drivers... oh the many drivers. Backwards compatibility has always been a problem as again, you can't reasonably expect a vendor to support old programs in perpetuity.
Also, as a non-Mac user I know that Ap
Re: (Score:2)
There's a difference between supporting it and EOL'ing it. If it's a game we paid for, at the same cost as the windows users, it's totally reasonable to expect the mac version to run as long as the windows version of the exact same game. (Team Fortress 2 in my case)
I understand there are back-end development costs, but from a USER standpoint, this is the same as a dealership saying they could no longer work on a red car but the blue ones of the same year and model (the same game) can still be maintained.
Main problem, Can't play w/o Steam eventually ? (Score:2)
Enshitification like it's 1980 again marches on (Score:2)
"Drops" means they added support for it? (Score:2)