News for hackers. Stuff that matters.
Re:Win32 on macOS by kccqzy on Saturday December 14, 2019 @02:32AM (#21788319)
> Speaking of code segments, the big thing that Catalina provides that enables this all to work is the ability to create 32-bit code segments in a 64-bit process. For that, they enabled the use of i386_set_ldt() in 64-bit processes. The big caveat though, is that this functionality is restricted by System Integrity Protection (SIP). For now, your best bet to get this working for yourself is to disable SIP. (CrossOver doesn't require that, but the mechanism by which we accomplish that is in flux internally to Apple. When it settles down, I'll update this thread.)

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).

Re:Win32 on macOS by throwaway884840 on Saturday December 14, 2019 @06:19AM (#21788928)
> 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.

Re:Win32 on macOS by asveikau on Saturday December 14, 2019 @12:24PM (#21790642)
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.

Re:Win32 on macOS by blinkingled on Saturday December 14, 2019 @03:45AM (#21788506)
Apple has some weird history with doing crazy things with 32b/64b stuff just because they can - back in the Intel 64 early days they ran a 64-bit kernel that loaded 32-bit device drivers. I don't know if anyone has still figured out the how and why of it!
Re:Win32 on macOS by brigade on Saturday December 14, 2019 @04:11AM (#21788577)
They didn’t load 32-bit drivers in a 64-bit kernel; rather they ran a 32-bit kernel that supported 64-bit userspace processes.
Re:Win32 on macOS by blinkingled on Saturday December 14, 2019 @10:54AM (#21790092)
You may be right but I remember both of those things - supporting 64-bit apps on 32-bit kernel and loading kexts that didn't bit-match the kernel. Long time ago so not sure.
Re:Win32 on macOS by sigjuice on Saturday December 14, 2019 @02:59PM (#21791782)
Non-matching kexts was never a thing.
Re:Win32 on macOS by exikyut on Saturday December 14, 2019 @04:32AM (#21788633)
That's even crazier. How and why??
Re:Win32 on macOS by lgg on Saturday December 14, 2019 @05:41AM (#21788809)
When the first 64 bit Macs shipped none of the software was 64 bit clean. Even if the kernel source code had been 64 bit clean, it would have broken support for all the the 3rd party 32 bit drivers that existed.

So the kernel switched itself in 32 bit virtual mode, though some parts of the pmap layer understood 64 bit page tables in order to manage the 64 bit physical address space. While the kernel could not see all of memory, it did not need to, it could map any apertures it needed in by manipulating its own page tables.

At that point it is pretty trivial to setup a 64 bit address space for a process. The kernel could not directly map all of virtual address range of the process at once, but it already had the pmap and aperture management code to deal with that. That decoupled 64 bit user space bringup from the 64 bit kernel port. The first release that supported 64 bit processes did not have 64 bit UI frameworks, just the C library and some low level posix functionality, but it allowed scientific code that benefited from more memory to run.

Re:Win32 on macOS by wtallis on Saturday December 14, 2019 @05:24AM (#21788771)
Apple started working on 64-bit application support back when they were still on PowerPC, where they only had 64-bit for desktop processors, not laptops. Then the first round of Intel Macs had 32-bit Core Duo processors. Less than a year later the second round introduced 64-bit Core 2 Duo processors that were pretty much a drop-in replacement, and at the time it certainly didn't make sense for Apple to overhaul their EFI, kernel and drivers with a 64-bit transition only 9 months after switching from PPC to x86.

Support for 64-bit GUI applications on OS X didn't arrive until 2007, a year after Intel Macs started using 64-bit processors. Support for running a 64-bit kernel arrived in 2009, and only for machines that had 64-bit EFI firmware. In 2012, Apple dropped support for the machines that had 64-bit processors but used 32-bit EFI, so from that point on they were handling the 64/32-bit mix the same as other operating systems.

Re:Win32 on macOS by toyg on Saturday December 14, 2019 @02:49AM (#21788358)
Maybe they plan on doing a big show and dance when they “settle” the issues around SIP: “macOS now allows you to run classic apps and games!!!!”