3 ms·

I worked at Apple during the 64 bit transition. The answer is that 32 bit was quite painful to maintain. The 64 bit transition was a compatibility break that e

I worked at Apple during the 64 bit transition. The answer is that 32 bit was quite painful to maintain. The 64 bit transition was a compatibility break that enabled shedding technical debt, like NeXT-isms that no longer applied. In particular it added the ObjC 2 runtime, which allowed features like adding a variable to a class without needing to recompile subclasses. So long as 32 bit is supported, it is difficult for Apple to use these features internally. If you add a variable to a class you break the 32 bit system. If you add a variable conditionally under an #ifdef then it is annoying to manage the separate build configurations, or disparate 32bit/64bit behaviors. This only applies to the Mac; iOS always had the modern runtime. But macOS engineers are very very happy to see 32 bit go because it was painful to support.

kevingadd 7y ago
Would you say this is due to architectural limitations in how 32/64-bit are implemented in OS X, vs the way compatibility works on say Windows or Linux? I know people have claimed that part of this is due to the need for system binaries/etc to all include full 32/64-bit versions.
- yyyk 7y ago
  Windows 64bit mostly uses 32bit shims which call the 'real' 64bit API. This means that 32bit support is almost no-cost to maintain - I am certain MS will support 32bit for the next decade at the very least - but at the cost of having the 64bit API itself slightly less breaking compatibility so shims are easier to make (e.g. "long" is still 32bit). Arguably MS would have made the same API compromises anyway just to make porting easier. Linux has some 32bit shims in the kernel and a few separate syscalls, but userland does the separate libraries approach where all 32bit libs are separate than 64bit libraries. So the kernel pays a small cost, while userland needs to maintain separate versions of the libraries - which often costs very little (many can simply be recompiled, this is open source after all), but can bite the maintainer sometimes. MacOS uses the fat binaries approach, where every binary carries all the arch versions. I don't think the system supports a different method - so Mac pays a bigger cost than Windows or Linux in order to maintain 32 bit. Also Mac kernel API is unstable by design, and I guess Apple would like to drop some older stuff. For better or worse that's the Apple Way - they don't maintain anywhere as much backward compat as other platforms.
renaudg 7y ago
Thanks. This should be the top comment for every Catalina rant posted here.
- markmark 7y ago
  As a user, why would I care how inconvenient it is for a trillion dollar company to support their software?
  - dkonofalski 7y ago
    It's not their software that's breaking. It's software that hasn't been updated that's breaking.

kevingadd 7y ago

Would you say this is due to architectural limitations in how 32/64-bit are implemented in OS X, vs the way compatibility works on say Windows or Linux? I know people have claimed that part of this is due to the need for system binaries/etc to all include full 32/64-bit versions.

yyyk 7y ago
Windows 64bit mostly uses 32bit shims which call the 'real' 64bit API. This means that 32bit support is almost no-cost to maintain - I am certain MS will support 32bit for the next decade at the very least - but at the cost of having the 64bit API itself slightly less breaking compatibility so shims are easier to make (e.g. "long" is still 32bit). Arguably MS would have made the same API compromises anyway just to make porting easier. Linux has some 32bit shims in the kernel and a few separate syscalls, but userland does the separate libraries approach where all 32bit libs are separate than 64bit libraries. So the kernel pays a small cost, while userland needs to maintain separate versions of the libraries - which often costs very little (many can simply be recompiled, this is open source after all), but can bite the maintainer sometimes. MacOS uses the fat binaries approach, where every binary carries all the arch versions. I don't think the system supports a different method - so Mac pays a bigger cost than Windows or Linux in order to maintain 32 bit. Also Mac kernel API is unstable by design, and I guess Apple would like to drop some older stuff. For better or worse that's the Apple Way - they don't maintain anywhere as much backward compat as other platforms.

renaudg 7y ago

Thanks. This should be the top comment for every Catalina rant posted here.

markmark 7y ago
As a user, why would I care how inconvenient it is for a trillion dollar company to support their software?
- dkonofalski 7y ago
  It's not their software that's breaking. It's software that hasn't been updated that's breaking.