Dropping Binary Compatibility With Previous Versions

Apple did this in 2000. At the same time, they also completely scrapped their old codebase, a move that was long overdue. The old Mac OS didn't have real multitasking, a sane framework for non-GUI programs, memory protection, ... in short, it was in much worse shape than Windows, technically speaking. Apple had concentrated totally on the UI, and that was not sustainable. UI is important, but you have to have a strong foundation to build it on.

Anyway, my point is, while Apple needed to make huge changes, and Microsoft can probably get away with smaller changes, dropping binary backward compatibility with old system libraries is something every OS has to do periodically. Only, until now, Microsoft has only done it gradually, piecemeal, and by accident. (If you try to run software designed for a long-dead version of Windows you'll discover what I mean. Little things will just not quite work right.)

As this article notes, the attempt to retain binary backward compatibility across multiple versions costs something. Now Microsoft wants to free itself from those costs, as Apple did with the release of OS X.

Most Unix systems don't incur these costs in the first place, at least not in the same way, because they don't worry so much about binary compatibility. They don't need to, because they have source compatibility. In an enviroment where you have the source code for everything anyway, you can just recompile as necessary when you upgrade to a new version of the core system. (Take this philosophy to its logical extreme and you get Gentoo, or the BSD ports system, where the user's system recompiles everything from scratch, locally, every time they upgrade anything. But the distributor can also pre-compile the software for each major version of the OS and make pre-compiled versions available, which is what most distributors do, because it makes upgrades faster for the user.)

But Apple and Microsoft both rely heavily on proprietary third-party software, for which source code is not available, except to the ISVs who produce the software -- and they cannot always be relied upon to do any porting, especially not punctually; Apple had significant trouble getting Adobe to finally support the new version, and they still haven't moved to Cocoa, most of a decade later. Microsoft doesn't rely as heavily on any single ISV as Apple does on Adobe, but that's only because the stuff they rely on is spread out over a larger number of ISVs. So they have to think about this issue.

The logical solution is to do what Apple did: supply an emulated old-version environment for running old-version software, with all the performance penalties that implies. Software that is updated promptly can be run natively, with the advantages that go along with that. I don't think they can afford to do this every major version, but at this point they're well overdue for it.

Whether they'll actually do it is an open question. I don't know whether Dev Corvin actually has any significant inside information, and of course it's so early in the Windows Seven development timeframe at this point that any decision that's made can potentially be changed several times before release. Nonetheless, it's an interesting point.

Whether (and how) this figures on my timeline is also another question. Assuming it's a for-real announcement originating from Microsoft, it would be a fairly sweeping technical announcement of the general type that my timeline has slated for 2010. But it's not related to security, and there was only one sentence about how this sort of thing is good for developers, and it's not clear that even that sentence necessarily means third-party developers. So I'm not sure there's a specific timeline entry to pin this on.