Why? Sometimes functionality has to be exposed, even when a company would prefer an alternative. Microsoft has named functions similarly on occasion [1].
[1] http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296...
[1] http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296...
Things got even worse in Windows 95, when all our window procedures were converted to 32-bit versions. The problem is that the old window procedures were only 16-bit. So we couldn't even simply export the 32-bit window procedure under the name BOZOSLIVEHERE. We had to write a conversion function that took an illegal 16-bit function call and converted it to the corresponding illegal 32-bit function call.
Apple just says "that's obsolete in a year" and lets everything break (or have it removed from its marked).
Granted, you can clearly see what approach gives you the best long-term agility, but still: there are few companies which has historically supported applications and ensuring compatibility like Microsoft did.
That does deserve a bit of respect.
Carbon is now _15 years old_, you know...
That sort of attitude is very different from the one highlighted in the linked MSDN blog where they are building compatibility bridges for illegal, abandoned APIs which were never meant to be public in the first place, to ensure that the application people care about keep working.
Ofcourse, in a pre-internet time, where applications couldn't deliver timely updates, and definitely not automatically nor over-the-wire (since there was no wire), this was a much more pressing concern than now, but that still doesn't detract from the fact that Microsoft deserves some credit for their efforts.
When Apple did the architecture shift from PowerPC to Intel they provided the Rosetta bridge that allowed PowerPC code to be ran under Intel architectures. They introduced that in 2005 and removed in in 2011. Developers had a pretty long time to get over it.
And this wasn't even the first time. Recall the 68k emulator that shipped in all classic PowerPC Macs.
Both Microsoft and Apple deserve enormous credit for their compatibility work. But Apple deserves special mention for shepherding the Mac through three completely different architectures (68k->PPC->x86) while maintaining excellent compatibility at each transition. Windows has also gone through significant transitions, but within the same x86 processor family.
Admittedly, all the other architectures Windows supported apart from x86 were added and later dropped again, so it were more sidesteps instead of transitions.
Not really. Applications sometimes break from version to version, but usually due to use of undocumented behaviour etc; APIs are rarely deprecated.
> When Apple did the architecture shift from PowerPC it "was get over or get out".
PPC was supported for five years after the shift...
(some may not get the reference :P)