5 ms·

Why? Sometimes functionality has to be exposed, even when a company would prefer an alternative. Microsoft has named functions similarly on occasion [1]. [1] h

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.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296...

chatman 13y ago
Because he might've appreciated better variable naming. :-P
- tekacs 13y ago
  isTheTimesAChanging ? (some may not get the reference :P) (http://youtube.com/watch?v=9TzhTqzXFgQ http://youtube.com/watch?v=9TzhTqzXFgQ)
josteink 13y ago
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.
- rsynnott 13y ago
  > Apple just says "that's obsolete in a year" and lets everything break Carbon is now _15 years old_, you know...
  - josteink 13y ago
    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.
    - nicholassmith 13y ago
      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.
    - millstone 13y ago
      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.
      - ygra 13y ago

chatman 13y ago

Because he might've appreciated better variable naming. :-P

tekacs 13y ago
isTheTimesAChanging ? (some may not get the reference :P) (http://youtube.com/watch?v=9TzhTqzXFgQ http://youtube.com/watch?v=9TzhTqzXFgQ)

josteink 13y ago

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.

rsynnott 13y ago
> Apple just says "that's obsolete in a year" and lets everything break Carbon is now _15 years old_, you know...
- josteink 13y ago
  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.
  - nicholassmith 13y ago
    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.
  - millstone 13y ago
    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.
    - ygra 13y ago