Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Games IT

Valve To Drop Steam Support For 32-Bit Windows Versions Next Year (tomshardware.com) 39

Valve is dropping support for Steam running on 32-bit versions of Windows, starting January 1, 2026. A report adds and comments: Steam has been available on Windows for more than two decades and, therefore, was built with 32-bit systems in mind. Today, every modern computer is 64-bit, with compatibility layers built in to support older 32-bit apps. So, even though 32-bit apps have carried forward, there's really no place for 32-bit operating systems anymore -- which is why Valve is axing support for them.

Valve To Drop Steam Support For 32-Bit Windows Versions Next Year

Comments Filter:
  • by JamesTRexx ( 675890 ) on Friday September 19, 2025 @08:13AM (#65670220) Journal

    It's a good thing my Windows 7 game laptop is 64 bit.

    • Given that you say "game laptop" and that you can run Steam at all, that's obvious.

      In the last two decades, all 32-bit machines were either embedded, or 64-bit CPUs with a broken BIOS made by idiot vendors for the lowest tiers of the market -- while laptops marketed as game are mid to high end. And I don't think those broken BIOSes were sold anymore after 2010 or so.

      Meanwhile, Steam and games do use opcodes added to the ISA a lot later than that, with no fallback. They do use opcodes from newer ISAs, and

  • Just ship with all the 32 bit libraries already, so we can stop needing multiarch for Steam.

    • Just ship with all the 32 bit libraries already, so we can stop needing multiarch for Steam.

      As long as distros continue to do the work to build 32-bit libraries, why should they? Canonical (as one of the largest desktop distributions) needs to announce the end of multiarch as a forcing function to see it happen (FWIW, some enterprise distributions have entirely dropped 32-bit libraries, but those are not expected to be used for desktop gaming).

      • by mccalli ( 323026 )
        That's chicken and egg though. I use Bazzite, Fedora Kinorate with some gaming tweaks. Fedora wanted to drop 32 bit and there was a lot of noise as things like Bazzite or any gaming usage at all from that distro would break.

        But, if Steam went 64 bit then that's 80%-90% of the issue solved straight away, and the last 10-20% would quickly sort themselves out in response. Summary is the distros have already indicated they don't want to do the work, and it's userland that's holding them back right now. Would
        • by mccalli ( 323026 )
          gah - Kinoite. Spelling.
        • But, if Steam went 64 bit then that's 80%-90% of the issue solved straight away

          Actually, not for all. While steam being 64-bit would be good (and likely will happen at some point (it is already true for Apple systems)), some games themselves need 32-bit libraries, and unless steam ships the libraries themselves, the games will not run. If Canonical dropped 32-bit libraries, Valve would need to provide the 32-bit libraries for the 32-bit games (and then steam would also have access to those libraries).

          • by mccalli ( 323026 )
            It's mostly WINE though isn't it? Well, Proton but still. That has the 64bit-32bit thunking layer required. Native Linux builds would need to be 64 bit true, but that's where I was going with the "10-20%" bit.

            I run 32bit Windows games on ARM via Rosetta/MacPortingToolkit. So long as the game itself is tricked into believing it's in a 32bit universe, it's happy.
    • Why? The point of multiarch is precisely to allow you to upgrade some software to a different arch while keeping support for old binaries that can't be recompiled.

      If not for political squabblings, we'd even have an arch for every major ISA bump or ABI break. But alas, some people are opposed to "arch proliferation" and we have to suffer stuff like that lib*t64 transition which added a lot of unnecessary work while breaking existing binaries.

      What you're preaching is multilib, which had been transitioned aw

      • Why? The point of multiarch is precisely to allow you to upgrade some software to a different arch

        Because multiarch sucks, especially if you're on Debian or a Debian-derived distribution, which most of us are. For some reason Debian is really bad at it and it causes a bunch of problems. Some things which really should be available in both architectures aren't.

        What you're preaching is multilib, which had been transitioned away for a good reason.

        No, what I'm preaching is more like appImages.

        • If you say "which should be available in both architectures aren't" then I guess you're using Ubuntu not Debian. In Debian, all release architectures had >=98% archive coverage since forever with few exceptions, never below 96%, and non-moribund -ports are also >= 90%.

          Things are worse outside Debian proper: for a time I maintained an out-of-archive arch but gave up because of the monstrosity that are binNMU version numbers. That's why derivatives (including even Ubuntu) use sourceful uploads for reb

          • If you say "which should be available in both architectures aren't" then I guess you're using Ubuntu not Debian.

            Actually, I'm using Devuan. But I had the same problem on actual Debian.

            As for appImages: they deserve no words other than an exorcism formula. Same for Snap.

            AppImages work, which is more than you can say for snaps.

  • by kackle ( 910159 )

    ... there's really no place for 32-bit operating systems anymore ...

    As an embedded software developer, I suspect that most operating systems are running on 32-bit ICs today. :)

    • Sorry, I've moved beyond definitions of specific numbers of bits.
      I'll just use however many bits the vibes tell me to.

      • I see you build hardware.

        Hardware guy once made an API for me that returned an 6 bit signed integer in an eight bit field, sign not extended. It was just easier for him. 21 bits, 25 bits, it didn't matter to him, it was all the same.
        • Re:32 (Score:4, Funny)

          by kackle ( 910159 ) on Friday September 19, 2025 @11:13AM (#65670556)
          I'll bet that had you chomping at the bit.
        • A chip that I played with a long time ago can only be programmed through 32-bit register access (limitation of the ARM bus). The address space for I/O peripherals can run out quickly and it's a hassle to move or expand them later. So a lot of small values get tightly packed into the register map. Here's one used for filter coefficients for the display.

          Horizontal scaling filter is a 6-tap filter with 4-bit positional phase.
          * Coefficients 0 and 5 are 3-bit signed value ranging from -4 to 3.
          * Coefficients 1 an

  • I'm not surprised that Valve is dropping 32-bit support; the 'gaming on 32-bit windows' market cannot be all that large or all that lucrative; what does surprise me a little bit is that the announced end of support doesn't line up with anything I immediately recognize. End of 2025/beginning of 2026 actually puts them considerably later than most stuff using chromium for UI rendering(not sure if they've been doing a bunch of backporting or if they consider the fact that they are mostly rendering their own co
    • by kcbnac ( 854015 )

      Windows 10 still has 32-bit editions - but hits EOL in October 2025 - Windows 11 is 64-bit only.

      Meaning aside from Extended Support options (which are critical security fixes only; and only offered for 1 year so far to the end-user - corporate customers can buy up to 3 years, at increasingly expensive rates.) there will no longer be a supported 32-bit Windows release. (Also ignoring Windows 10 LTSB - Long Term Stable Branch - mainly aimed at embedded systems; not 'generally available' to the gaming consume

    • The whole 32-bit Windows brouchacha comes only because of people not being told which arch to install. Microsoft had to keep 32-bit for a while because of 1. broken BIOSes in computers sold before ~2010, and 2. their software sucking balls when it comes to DLL hell. But then, if the installer shown them a popup like "you're installing 32-bit system on a machine capable of 64-bit, are you sure?", there wouldn't be a non-negligible install base anymore.

      Or alternatively, they could have implemented in-place

  • by Vandil X ( 636030 ) on Friday September 19, 2025 @09:34AM (#65670354)
    RIP to all the hobby machines running 32-bit Windows for old games. Download your archival copies now.
    • by Guspaz ( 556486 )

      The only 32-bit Windows version currently supported by Steam is Windows 10, and I doubt you're going to have any better compatibility with old games running the 32-bit version of Windows 10 than on the 64-bit version.

    • RIP to all the hobby machines running 32-bit Windows for old games. Download your archival copies now.

      Precisely no 32bit games are being dropped as part of this announcement. I have no problem running my entire steam library on 64bit hardware. The Steam client itself won't support 32bit going forward, that's no the same thing as 32bit games losing support.

      • I'm definitely not gonna be sad if the Steam client itself switches to 64-bit, but old game support in general is already a bit spotty, and I'm worried about unplanned regressions in support for some titles...

    • If you still run Windows games, then pirate instead of using DRM like Steam. They'll continue to work forever because of emulation.

  • This could have been a webpage.
  • when they support a two bit operating system.
  • I'm going to stop using Steam entirely because of this!

    Oh wait, I'm already not using Steam. But somebody had to say it! :-)

  • So, does this mean that the integrated WINE and DOSBox versions in all of the cross-platform games will finally be updated to 64 bit versions or be de-listed? There's a huge library of Mac games that are unplayable on modern versions of the OS because they are still running 32 bit WINE binaries.

This is a good time to punt work.

Working...