Hacker News new | past | comments | ask | show | jobs | submit login

Reading posts like this, you really can't deny that Microsoft is sometimes seriously underappreciated for their technical efforts at keeping everything running as smoothly as they can:

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.




> Apple just says "that's obsolete in a year" and lets everything break

Carbon is now _15 years old_, you know...


As far as I've understood it, iOS apps are under constant pressure to remain compatible with the latest APIs. When Apple did the architecture shift from PowerPC it "was get over or get out".

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.


Apple switched to Intel processors in 2006, but maintained support for running PowerPC apps on Intel processors up until OS X Lion shipped, in 2011. Apple kept compatibility with a completely different processor architecture for half a decade. When I got my first Intel Mac, I just copied over all my PowerPC binaries, and they ran fine. It was unbelievable.

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.


Remember Windows NT which ran on PowerPC, MIPS and Alpha. They even ran x86 binaries on Alpha which were not only emulated but also translated for later runs [1].

Admittedly, all the other architectures Windows supported apart from x86 were added and later dropped again, so it were more sidesteps instead of transitions.

[1] http://en.wikipedia.org/wiki/FX!32


iOS apps are encouraged to use the latest APIs to keep things moving forward so the hardware is used to it's fullest.

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.


> As far as I've understood it, iOS apps are under constant pressure to remain compatible with the latest APIs

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


I've got an app on my iPhone 4S w/iOS 6 that hasn't been updated since late 2008 (pre-iOS 3.0). It hasn't even been in the app store for years. Still works fine. Hopefully it'll work on iOS 7, too, but I haven't tried it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: