What bugs me is that in the case you link to, they've added more crap in an effort to support drivers which weren't written properly in the first place. Windows would be a far better product if they hadn't decided to adapt to so much improperly-written software and oft-needless backwards compatibility.
I much prefer Apple's approach with the switch to UB: they put in an emulator for PPC apps which basically sucks, thereby creating motivation for switching apps to the new format while still technically supporting legacy software. Now, in the upcoming version of OSX, that emulator cruft is being removed (last I checked).
Apple APIs are a huge pain in the ass to work with in the commercial world though since they're so volatile. With every 10.x release they seem to wipe out some huge subsystem and send everyone off to rewrite their code. As someone who used to maintain a set of cross-platform APIs built on top of Carbon, I learned to have quite a bit of respect for the cruft that sticks around in MFC.
I realize that, and I can empathize with your plight. However, just as one would cull a herd or prune flowers, that cruft must also be removed sooner or later, else it will end up killing the entire system. Would this be a plausible explanation for why Windows performance continues to degrade substantially with each version?
personally, i'm with tdavis. the level of cruft in windows is strangling it to death. the idea that they'd go so far as to make a fake window so display drivers can maul it is going WAY too far.
if you've got old programs that you really can't do without, then stick with older versions of windows.
I'd agree with that - I haven't developed for Apple, but we run quite a few old applications for Windows at work, and it would be a big problem for us if they stopped working in a new version of Windows.
Removing the old cruft means that old apps stop working; some of those old apps are quite good, and it seems a shame to reinvent the wheel (rewrite new versions of old applications) for each OS release, so I'd definitely favour a balanced approach to removing old APIs (where balanced means trying to assess the amount of applications still in use that are likely to be affected by the change).
