>What was the alternative? Sticking with 65x02, 68K, or PPC?
No, including an interpreter like they did (Rosetta) was an alternative. The "alternative" really depends on what the goals were. For Apple, their goal is modern software and hardware that works together. That's antithetical to backwards compatibility.
>They could have stuck with x86 I guess. But was moving to ARM really a bad idea?
I don't think I ever suggested that it was or that they couldn't have...
>They were able to remove entire sections of the processor by getting rid of 32 bit code and saving memory and storage by not having 32 bit and 64 bit code running at the same time.
Yes, and, in doing so, they killed any software that wasn't created for a 64-bit system. Again, for even a purely historical perspective, the amount of software that didn't survive each of the instanced transitions is non-negligible. Steam now has an entire library of old Mac games that can't run on modern systems anymore because of the abandonment of 32-bit without any consideration for backwards compatibility. Yes, there are emulators and apps like Wine and CrossOver than can somewhat get these things working again but there's also a whole subsection of software that just doesn't work anymore. Again, that's just a byproduct of Apple's focus on modern codebases that are currently maintained but it's still a general detriment that so much useable software was simply lost immediately because of these changes when there could have been some focus on maintaining compatibility.
> No, including an interpreter like they did (Rosetta) was an alternative.
The downside of including an interpreter with no end of life expectations is that some companies get lazy and will never update their software to modern standards. Adobe is a prime example. They would have gladly stuck with Carbon forever if Apple hadn’t changed their minds about a 64 bit version of Carbon.
That was the sane reason that Jobs made it almost impossible to port legacy text based software to early Macs. Microsoft jumped onboard developing Mac software and Lotus and WordPerfect didn’t early on.
But today you would have to have emulation software for Apple //es, 68K, PPC and 32 bit and 64 bit x86 software and 32 bit and 64 bit ARM (iOS) software all vying for resources.
Today because of relentlessly getting rid of backwards compatibility, the same base OS can run on set top boxes, monitors (yeah the latest Apple displays have iPhone 14 level hardware in them and run a version of iOS), phones, tablets, watches and AR glasses.
Someone has to maintain the old compatibility layers and patch them for vulnerabilities. How many vulnerabilities have been found in some old compatible APIs on Windows?
> The downside of including an interpreter with no end of life expectations is that some companies get lazy and will never update their software to modern standards. Adobe is a prime example. They would have gladly stuck with Carbon forever if Apple hadn’t changed their minds about a 64 bit version of Carbon.
I don't see that as a downside; I see it as a strength. Why should everyone have to get on the library-of-the-year train, constantly rewriting code -- working code! -- to use a new API?
It's just a huge waste of time. The forced-upgrade treadmill only helps Apple, not anyone else. Users don't care what underlying system APIs an app uses. They just care that it works, and does what they need it to do. App developers could be spending time adding new features or fixing bugs, but instead they have to port to new library APIs. Lame.
> Someone has to maintain the old compatibility layers and patch them for vulnerabilities.
It's almost certainly less work to do that than to require everyone else rewrite their code. But Apple doesn't want to spend the money and time, so they force others to spend it.
This may come as a surprise to you, but the vast majority of users absolutely hate it when their software changes.
They don't want all new interfaces with all new buttons and options and menus.
People get used to their workflows and they like them. They use their software to do something. The software itself is not the goal (gaming excepted).
I'm not suggesting that things should never be gussied up, or streamlined or made more efficient from a UX perspective, but so many software shops change just to change and "stay fresh".
I'm not sure why you're responding to me. Nothing that you're saying is anything that I've mentioned or brought up. I know what the downsides are. I'm just saying that the goals that Apple has optimized for have resulted in a loss of things that many would consider valuable.
If Apple users really appreciated backward-compatibility, the would be a significant market for 3-rd party emulators and VMs to run old software using no longer supported hardware or software API. It is not there. There are VMs, but they are mostly used by developers or by people who want to run Windows software on Mac, not old Mac software. So from Apple perspective if their users do not want to pay for backward compatibility, why should Apple provide it?
I wonder how much of that is just lack of awareness. E.g., the whole story at [0] needn't have occurred if anyone involved were aware of VM emulation for older OS versions. But there's no money in selling old software, and Apple would probably open themselves up to lawsuits ("you told me to use a VM, and then it got hacked!") if they openly advertised it.
No, including an interpreter like they did (Rosetta) was an alternative. The "alternative" really depends on what the goals were. For Apple, their goal is modern software and hardware that works together. That's antithetical to backwards compatibility.
>They could have stuck with x86 I guess. But was moving to ARM really a bad idea?
I don't think I ever suggested that it was or that they couldn't have...
>They were able to remove entire sections of the processor by getting rid of 32 bit code and saving memory and storage by not having 32 bit and 64 bit code running at the same time.
Yes, and, in doing so, they killed any software that wasn't created for a 64-bit system. Again, for even a purely historical perspective, the amount of software that didn't survive each of the instanced transitions is non-negligible. Steam now has an entire library of old Mac games that can't run on modern systems anymore because of the abandonment of 32-bit without any consideration for backwards compatibility. Yes, there are emulators and apps like Wine and CrossOver than can somewhat get these things working again but there's also a whole subsection of software that just doesn't work anymore. Again, that's just a byproduct of Apple's focus on modern codebases that are currently maintained but it's still a general detriment that so much useable software was simply lost immediately because of these changes when there could have been some focus on maintaining compatibility.