Binary (In)Compatibility
A coworker forwarded me an interesting piece from OSNews on how Microsoft can prevent another poor development cycle like it had for Vista when it engineers “Windows 7.” The crux of the piece is that Windows should abandon its current userland code and break binary compatibility with the mountains of code that has been written for the WinTel platform ever since DOS was all the rage.
Quoth the article:
… For programmers, however, this desire to maintain backwards compatibility is a potential hell. This means that if you, as a Microsoft employee, have come up with a new killer feature, or maybe something less significant like a fix for long-standing minor bug, it needs to pass through a long process of testing to ensure backwards compatibility is not affected by your code. And if it does affect compatibility, your code needs to be rewritten, or, new patches need to be made to fix the compatibility breakage caused by your original patch. You can easily see how something like this is a restraint on many developers, and how it can hold back many envisioned improvements.
The author suggests freezing the “legacy edition” codebase with Vista or Windows Server 2003 and then only maintaining it with bug fixes and security updates while pressing on with development of a new codebase that is based on the NT kernel but with a new userland to be filled with new APIs and applications:
… Removing backwards compatibility means business users would never buy into Windows 7, and that would mean a serious lack of cash-flow for Microsoft. Therefore, Microsoft needs to cater to business users and other people concerned about backwards compatibility by maintaining a version of Windows based on the ‘old’ Windows NT; call it Windows Legacy, if you will. This version of Windows would be Vista (or, more preferably, Windows Server 2003), receiving only security updates and bug fixes.
An alternate and arguably preferable solution would be a black-box compatibility environment for the old apps, similar to Classic and Rosetta, which have helped ease Apple through some operating system and hardware architecture transitions.
The author somewhat underestimates the engineering effort involved with maintaining an operating system fork (winning quote: “Would this require more developers than are currently needed? I doubt it.”) and too easily casts aside the reasons for application compatibility. A particular failure is that the author only seems to consider how businesses would handle the issue, and doesn’t consider end-user impact. Namely, every user would be forced to replace every application they own, and a large number of “fringe” applications will never be revised. The user is left with the choice of paying to stay on an outdated operating system (no sale, frustrated user) or paying more to get onto an incompatible one (sale, frustrated user).
My take, of course, is that maintaining compatibility with at least the bulk of the most important apps on the platform is worth the engineering effort. I could be biased, though, given that it’s part of my job


