Comment by gonzalohm
8 hours ago
How is that possible? 32 bits should be compatible with a 64 bit machine. You can always use less bits for your memory addresses.
Are there any other architecture changes that are preventing 32 bits binaries from running? Does that also mean that old software no longer runs unless there is a 64 bit version?
In windows you can run x32 and x64 executables in a 64 bits machine
Monsieur, on Windows this problem was solved with a large development effort, that's why it goes unnoticed on you. Note that CPU level instruction emulation is literally the easiest problem of emulation. (Why do you think you can't just go and execute Nintendo Switch binaries on your Mac M1? Both run ARM64.)
On Windows, this was is implemented as SysWOW64. WOW64 means Windows on Windows 64. It makes the userland emulation and pretends towards the process that everything around him (incl. drivers) are the 32-bit ones.
Source: Microsoft.
https://devblogs.microsoft.com/oldnewthing/20081222-00/?p=19...
One of the big things here is that Intel and ARM processors are backwards-compatible with 32-bit instructions, even if they are 64-bit processors. Apple Silicon on the other hand is not, which is why Apple completely dropped support before switching.
WOW64 is not emulation, it's just a second set of libraries exactly like the ia32-libs package on linux. OSX used to have this too but i guess apple got tired of maintaining it
Only the very first few models of Intel Macs had strictly 32-bit processors (the 2006 iMac and Mac minis with Core Solo/Core Duo processors), and none of them were realistically capable of playing Half-Life 2. Apple is guilty of many sins, but this isn't one of them. Valve should never have shipped a 32-bit application in the first place. The binary was already obsolete before it even left Bellevue.
> Valve should never have shipped a 32-bit application in the first place.
It's literally a 2004 game! That's ridiculous. A handful of opterons existed in the market, but Intel wouldn't get there for years still and it was well over a decade until x86_64 crossed 50% market share in consumer stuff.
Good grief, as it were.
In 2004, sure, but Valve didn't (publicly) ship Mac OS X software before 2010.
3 replies →
> Only the very first few models of Intel Macs had strictly 32-bit processors (the 2006 iMac and Mac minis with Core Solo/Core Duo processors), and none of them were realistically capable of playing Half-Life 2.
What? First, those chips were plenty powerful to run HL2 (the game predates them). And second, all x86_64 chips can run older x86 32-bit code unmodified.
The reason macOS stopped supporting 32-bit code has nothing to do with the processors but more about them wanting to remove support for 32-bit binaries from the kernel and from all user-space libraries. To run a 32-bit binary, you need itself and all libraries it depends on to be 32-bit too, including the syscall boundary, which is "fine" (both Windows and Linux do this just fine, so it's really on Apple to have removed this). And I suppose Apple removed those because it was building towards a 64-bit-only world to simplify the Apple Silicon transition.
The CPUs were powerful enough, sure. The GPUs (Intel GMA950) absolutely weren't. Even on Windows with better drivers, Half-Life 2 is a slideshow on that class of hardware.
Apple goes way out of their way every few years to ensure old games stop working
The don’t let backwards compatibility stop them from doing anything, but I don’t think they go out of their way to target games. That doesn’t make any sense to me.
All 32-bit support got dropped, so you're totally right. It might appear to target games because games are disproportionately likely to not get updated to new archs and to be run long after they were introduced. Nobody is going back to run some 32-bit-only RSS reader or text editor from 2007 even though there surely were some.
In the case of hl2 the source code for the engine has leaked, so you can recompile it for your target platform of choice, no "conversion" needed. I got it running natively on aarch64 linux a while back, with no issues.
So why can’t Valve do it?
Not a priority I guess.
Everything in the process has to agree on how big the pointers are, or you need code to convert between the formats at the boundary. That means you either need 32-bit versions of all OS libraries, or you need a complicated shim layer. Apple went for having 32-bit versions of all OS libraries. But this isn't free to maintain, and they dropped them after a few years.