3 ms·

> This is quite curious. Apple inconvenienced so many users by "removing" 32-bit support on Catalina, and then they added support for local descriptor tables? I

> This is quite curious. Apple inconvenienced so many users by "removing" 32-bit support on Catalina, and then they added support for local descriptor tables? I'm not aware of any use of LDTs on modern systems (except perhaps Chrome for additional sandboxing). For the specific purpose of enabling CrossOver's 32-on-64 support and things like it. It's not too hard for the kernel to support user code merely entering the processor's 32-bit mode. CrossOver's processes don't even use 32-bit system calls or 32-bit Mach-O binaries, so support for those could hypothetically be removed, except that most of it is needed for watchOS anyway. But the most significant cost of i386 support was in userland, not the kernel: building separate x86_64 and i386 copies of every system library, and supporting the legacy i386 ABI, including an older version of the Objective-C runtime ABI. That's all gone now.

asveikau 7y ago
I am not privy to internal discussions, but it seems to me if there is really lots of ongoing maintenance needed at every release, and not simply exaggerating the need for occasional patches and bug fixes, then it is worth some consideration of re-architecting the way the compatibility mode works. eg. Maybe draw the boundary of where you thunk at a different place. Maybe do more translation in user mode as this wine project did. Or focus on binary compatibility with old, frozen-in-time frameworks instead of rebuilding them with every OS build. Obviously the specifics will vary with actual details of breakage. But from outside, it seems like these type of questions weren't pursued to their maximum extent, resulting in pain for the end user.