Hacker News Reader

Comment by sigjuice | Hacker News Reader

The 32-bit support is probably not easy to carve out into a separate self-contained package.

You literally need 32-bit builds of every system library & framework. That's the state of things in Mojave.

If you run `otool /System/Library/Frameworks/AppKit.framework/AppKit -f` you'll see 2 slices, one for "cputype 16777223" (CPU_TYPE_X86 | CPU_ARCH_ABI64) and one for "cputype 7" (CPU_TYPE_X86).

I don't expect new features to be implemented in 32-bit builds - maybe security patches at the most - so freezing it and keeping it as a separate package should be feasible.

This is exactly what Linux distros are planning to do.

Apple uses the concept of fat binaries, where single binary contains code segments for several architectures. Optional support would mean basically two versions of the entire operating system: one supporting only 64 bit, and the second supporting both, 32 and 64 bits.

Linux solves it differently, it uses separate binaries for separate architectures. You can install the libraries into separate paths, have separate dynamic loader and everything works. Apple has no such option.

Also, macOS has a lot of system libraries that do IPC to either system daemons or kernel drivers, where the library exposes a stable API/ABI, but where the IPC interface itself has absolutely zero stability guarantees. This is because the library and the daemon/driver are developed together as part of the same codebase; users are expected to upgrade them in lockstep as part of an OS update, and to always use the library to talk to the daemon/driver rather than reimplementing the IPC yourself. This way, the developers only have to manage one stable interface (the library) rather than two (the library as well as the IPC interface). But that means you can’t just freeze the version of the library and expect it to work with newer daemons/drivers. In theory Apple could change course and decide that all system IPC interfaces must be kept stable starting now, but that would be really annoying, and probably more work than just continuing to update the 32-bit libraries.

(This even applies to the base Unix system calls. Go previously did syscalls by hand but recently switched to dynamically linking against libSystem and using its wrappers, because they’re the only guaranteed-stable interface.)

This explains the downvotes. I did some googling and noticed "Universal Binaries" mentioned in the results, which I remember in the 00s but had no idea that was remotely related to the OS binaries themselves.

Reply on news.ycombinator.com