2 ms·
32 bit code is stuck with the older ObjC runtime, which can’t support a bunch of new language features and suffers from from fragile ABI issues which make chang
by msbarnett 7y ago
32 bit code is stuck with the older ObjC runtime, which can’t support a bunch of new language features and suffers from from fragile ABI issues which make changing the internals of classes extremely problematic.
It’s not simple to fix (“just upgrade the runtime to support the new features”) because the newer runtime trades on the fact that a bunch of unused space in 64 bit pointers can be exploited for tagging, pointerless classes and a bunch of other things. And if they did fix the fragile ivar problem on the 32bit runtime, you’d need to recompile to use the new way of dynamically calculating strict offsets to member fields — and these apps are mostly dying with 32bit precisely because no one is recompiling them.
It’s basically dead-end code that is difficult to maintain and which increasingly requires the rest of the OS to stagnate just to keep it running.
- mrpippy 7y agoAlso: the Carbon API set is only supported on 32-bit, and removing 32-bit means all of Carbon can go away. Carbon is a massive API set, with one or sometimes two full legacy APIs (often dating back to the 90s) for everything. Drawing (QuickDraw), multimedia (QuickTime), open/save dialogs (NavServices), fonts/text rendering (Font Manager, ATSUI), windows/menus/dialogs (both HIToolbox and the classic Managers), file I/O, printing, and on and on. Keeping all this stuff functional (to support old apps) while evolving the system underneath is a huge burden which will be lifted from 10.15 on.