Given the vast difference in power, it’d probably have been enough to just cascade all the various layers they already have. Arm > x86 > ppc > 68k

Even if each layer loses, say, 50% performance, the fastest 68k was only 75mhz.

(Although now that I think about it I think the handled the 68k/ppc transistion by just making everyone compile for both and slap em into the same binary. Memory is hazy.. it’s been at least 20 years since I’ve touched a classic mac)

You're confusing the "fat" binary format that allowed developers to ship the same application file for both 68k and PowerPC with the emulator that allowed for compatibility with existing 68k code. Much of the OS and apps remained 68k to the end of classic Mac OS's life.

Yes, Apple only cares about allowing supported software to easily keep running. This means they can implement more modern and secure systems than Microsoft is able to achieve. It's also the reason Windows is plagued with 32 bit software currently in development as MS has no way to push for the removal of obsolete features.

And also the reason why no large company will touch macos (and I imagine it is the same thing server side).

> It's also the reason Windows is plagued with 32 bit software currently in development

What's wrong with 32-bit software? If you don't need more than 4GB of virtual memory, you've got half the memory footprint for pointers.

One major issue is it can't handle dates any further than 2038 which is getting uncomfortably close, especially when you have to handle future dates.

Windows doesn't use UNIX time. The SYSTEMTIME structure can go up to the year 30827. See https://learn.microsoft.com/en-us/windows/win32/api/minwinba....

64-bit time_t works perfectly fine on 32-bit systems. That is completely unrelated to machine word size.