Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
OS X Games

Steam Drops macOS Mojave Support, Effectively Ending Life For Many 32-Bit Games (arstechnica.com) 71

Posted by BeauHD from the no-loner-supported dept.
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.
This discussion has been archived. No new comments can be posted.

Steam Drops macOS Mojave Support, Effectively Ending Life For Many 32-Bit Games More

Steam Drops macOS Mojave Support, Effectively Ending Life For Many 32-Bit Games

Comments Filter:

  • They will still works, just no updates (Score:3)

    by JcMorin ( 930466 ) on Thursday November 30, 2023 @11:47PM (#64045567)
    It make sense for Valve at some point to stop supporting old stuff, the good news is it should continue to work "as is". Those that play old game, don't need the new online stuff anyway.

    • Re:They will still works, just no updates (Score:4, Interesting)

      by Baron_Yam ( 643147 ) on Friday December 01, 2023 @12:10AM (#64045611)

      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)

        by Anonymous Coward

        I am happy they only drop support for 32 bit games so my 16 bit games should keep working!

      • Re:They will still works, just no updates (Score:5, Insightful)

        by Moryath ( 553296 ) on Friday December 01, 2023 @01:30AM (#64045729)
        You've basically just explained why "piracy" is so important to game preservation.

      • Re: (Score:3, Insightful)

        by thegarbz ( 1787294 )

        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)

          by Ksevio ( 865461 )

          I don't backup data that I can reinstall. It's a waste of backup resources.

          • 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

          • 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)

              by Ksevio ( 865461 )

              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)

        by Entrope ( 68843 )

        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".

      • Probably not, but tou can get the games without Steam's hold over them.

      • 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.

    • 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

      • you can still login in steam even on xp but downloads and the store is broken. you need to use a newer pc to rebuild the libary if you did lose it.

  • 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)

      by Camembert ( 2891457 ) on Friday December 01, 2023 @12:53AM (#64045685)
      indeed no 32 bit apps anymore, which for revisiting old games can be a pity.

      • 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.

        • It's not perfect, but I use crossover to play the windows version of the old game in 32-bit mode.

          • 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)

            • 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)

                by Malc ( 1751 )

                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.

                • You are correct, it's wouldn't.
                  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.

            • 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)

                by Malc ( 1751 )

                If you're on an Intel Mac, is a VM also an option?

                • 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)

                    by Malc ( 1751 )

                    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.

                    • 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

                    • 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

                    • 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

        • 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)

      by ArmoredDragon ( 3450605 )

      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)

        by vbdasc ( 146051 ) on Friday December 01, 2023 @05:52AM (#64045929)

        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.

        • 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

        • 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)

        by Malc ( 1751 )

        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: (Score:2)

      by antdude ( 79039 )

      Mojave v10.14 is the last one to support 32-bit. :(

  • 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)

      by Anonymous Coward

      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)

        by dgatwood ( 11270 )

        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)

          by Malc ( 1751 )

          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

        • 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.

        • 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)

            by dgatwood ( 11270 )

            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 (

            • 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

            • 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)

        by vbdasc ( 146051 )

        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?

    • You get what you pay for, which was ... *checks notes* ... $0.

  • Main problem is can you play those 32-bit games w/o being connected to Steam ? Or anyone game server: Epic games, etc ? !!! Can they be downloaded, played w/o hurting other downloaded game content that you had to have connected thru Steam ? Pay for it then can't play it. Same as for Blizzard, I paid for Diablo 1, have a license, yet I can't no longer down load it from them ! I miss so many great games that I played 20-25 years ago cause of planned obsolescence by computer companies ! Then we get into
  • The other problem is Steam isn't GOG. It can just reach into your Steam account and prevent you from using anything at any time. And there is no archival or emulation guarantee, so there is a death clock on every item "licensed" from Steam.
  • That's what drop means nowadays...

Slashdot Top Deals

Dynamically binding, you realize the magic. Statically binding, you see only the hierarchy.

Close