Linked by Kyuss on Mon 13th May 2013 01:31 UTC
Microsoft "Most people understand that Windows is used by a variety of people who have a variety of needs, ranging from corporate server to workstation to POS terminals to home PC and beyond. Most people accept that whenever Microsoft updates Windows, it has to balance the competing requirements to find some kind of workable compromise. There is however another set of competing requirements that many do not really register, even those that call themselves power users or are IT admins. It is a conflict between developers/programmers and Microsoft itself."
Thread beginning with comment 561452
To view parent comment, click here.
To read all comments associated with this story, please click here.
hhas
Member since:
2006-11-28

Mac OS9 --> OSX
required complete rewrites of almost all its apps


This is not correct. OSX included Carbon, which were a port of the classic Mac OS's more modern APIs retained for backwards compatibility. This allowed existing apps to make the transition without requiring a full rewrite to OSX's native Cocoa APIs. Obviously it wasn't a free transition: developers still had to replace any code that used really old, gnarly parts of the MacOS Toolbox that weren't supported in Carbon, update their GUIs for Aqua, and rebuild. But still far, far cheaper than a 'complete rewrite'.

Indeed, the whole reason Apple created Carbon in the first place was that major application vendors such as Adobe and MS would not - and could not - have ever undertaken major rewrites of their massive productivity apps. Without Carbon to make the transition to OS X cost-effective, those vendors would have simply abandoned the Mac platform altogether. And this was all back in the days when graphics and publishing were still core markets, a big chunk of income which Apple could not afford to lose.


This doesn't mean that Apple themselves ever saw Carbon as a full and permanent fixture in OS X, mind. The subsequent success of iPhone and iPad means that Apple's primary focus is now the iOS and consumer markets, and old pro app vendors and users carry much less weight. Thus Apple never included Carbon support in iOS, and has gradually superseded and/or eliminated various Carbon APIs in OS X, first reversing previous plans to make Carbon's GUI and QuickTime APIs 64-bit in 10.5, then legacying and/or deprecating many of the other Carbon APIs in 10.6 and 10.8.

This unpredictable, piecemeal hack-n-slash has caused some ruckus amongst longtime developers, peeved firstly at having to rewrite existing, mature Carbon-based code against Cocoa instead, and secondly that Apple's new 'replacement' Cocoa APIs are often inferior in quality and/or features to the Carbon ones. But so far the pain has been sufficiently spread out that developers have soaked it up over time. And even if it did spike to a level where a vendor like Adobe or MS decided to jump ship, this'd have less impact now on Apple's bottom line than it would've 15 years ago.

..

Microsoft, of course, are in a slightly different boat, since Windows' big selling point has always been that it is a reasonable jack of all trades, rather than the master of any one. I suspect Windows developer culture is also a bit more innately conservative, especially in the corporate field where ancient codebases tend to persist long after their best-by dates (something that Apple never has to worry about since it has no traditional corporate market anyway).

I suspect MS's current strategy does provide the best overall balance for both them and their users: freezing old, nasty APIs while retaining them long-term to ensure old extant apps continue to run, and focusing all their new development resources on clean, new APIs and features. Obviously, diehard users of the former are going to kvetch when they see users of the latter get all the shiny new toys; but then all those shiny new toys would probably never get created if MS had to spend all its days reflogging all its old, dead horses. You pays your money, etc.

Reply Parent Score: 3