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 suppor

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.