(06-22-2015, 06:31 PM)PaulD Wrote: But CI4, if the developers see good reason, should be free from the hassles, time and functionality constraints of upgrade considerations. If CI4 needs to be drastically different for any reason, then so be it. CI3 will still work, and if you want to take advantage of the CI4 benefits, then you do so at the cost of rewriting code. Otherwise you end up in a Microsoft position of supporting so many legacy systems that your new product is devoid of the real benefits it could have offered.
Honestly, despite the negatives, I think Microsoft can be used as a positive example in this instance. For example, you can still load a great deal of software in Windows 7/8 which was written for Windows 95/98/ME, even though they have to run in a compatibility layer because Windows 7 is not a direct descendant of those operating systems. Microsoft saw that it would be easier for them to create a series of compatibility layers for the Windows NT line of operating systems to run the majority of the legacy software designed for the Windows 9x and MS-DOS operating systems than to fix the underlying problems in the 9x line itself. The existing software tended to run a little slower and there were some growing pains, but somewhere between the release of Windows 2000 and Windows XP Service Pack 3 the developers had time to update their software to run as native applications.
Similarly, Windows Vista added some flashy GUI features and hardened the security, which exposed some issues with the permissions assumptions made by some applications (including some of MS' own software). Most of the developers eventually fixes these issues, but most of the users associated the issues with Windows Vista itself, so Microsoft re-branded and launched Windows 7, which users accepted as a great success. Windows 10 appears to be a similar effort for Windows 8, but I think the underlying problems with Windows 8 are less likely to have been fixed by 3rd party developers...
MS can go overboard with backwards compatibility, too. For example, with Internet Explorer they've maintained BC with their proprietary JScript/DOM and plugin functionality for so long past its useful lifetime that they've decided to introduce a new browser and keep IE around for backwards compatibility for Windows 10. However, they're sharing a lot of code between the two browsers, so IE could very well be seen as a compatibility layer which just requires a more explicit choice on the part of the user.
Even MS Office uses a compatibility mode to open documents in formats intended for older versions of the software.
In most cases, MS chooses to use a compatibility layer primarily to sandbox applications/documents, knowing that there are security risks associated with their older platforms which they can't tolerate in the newer environments. If all they need to maintain is an API, it's often much less difficult (for them and for users/developers), but APIs often don't stand up well when assumptions about the underlying system have changed.
If they choose to make CI4 in such a way that it is conceptually very different from CI3, it would make sense to use a compatibility layer simply because it might be easier to develop and maintain than it would be to keep the existing API intact. This may have some cost in extra development time, but it usually pays off by giving users a clear upgrade path (and reduces the need to maintain the previous version). After all, if the upgrade path from CI3 to CI4 is any more difficult than it is from CI2 to CI3, many more users would find the maintenance window before end of life on the old version unacceptable (especially if CI4 isn't in development and relatively stable as long as CI3 has been before its release).
