I've been exploring the relationship between Microsoft's Longhorn and other operating systems environments. That's a much more difficult task than you might think and it's not made any easier by the tendency of the research to throw up things that are, well, dumbfounding.
At the beginning Longhorn was a code name for an interesting set of ideas. Basically Microsoft was going to reinvent PICK in much the same way that Plan9 represented a reinvention of Unix. In effect Longhorn was going to migrate Microsoft's client-server ideas about how and why computers are used from their focus on stand-alone machines to a conceptualization based on a network environment. Like IBM's Cell, Longhorn was fundamentally to be about communication, not hardware.
The result might have been very cool, but that isn't what we're getting. Some bits are hard, some conflict with past practices, and others don't meet current agendas. As a result what we seem to be in for at the Windows level is more of the same old, same old -and all the baggage that goes with that.
The worst thing in Microsoft's version of iVMS, aka Windows 2000, was the morphing of the uaf facility into the registry. Longhorn apparently contains something both similar and worse called the Nexus.
The Nexus is basically a virtual machine within the machine that acts to authorize operations. At the hardware and operational level it does this by comparing device information (e.g. the CPU's unique identifier) to stored authorizations. If you're licensed it releases control to boot Windows, start the game, or show the movie -otherwise, well, too bad for you. On the application side the identification information is stored in a byte string obtained from the licensing organization and accesssible to an application embedded routine that profers it to the Nexus for authentication at start-up.
There are two things very badly wrong with this. One is complexity. When the USAF tried something like it for order authentication in the early seventies they discovered that moving authentication into the hardware created enormous delays when that hardware failed. You could not, for example, get a telex fixed in less than a month because the authentication for the hardware failure notice required the hardware to be working and the workaround protocol took weeks.
The other is that this seems primarily intended to support having the PC become the central device in home entertainment, but is actually a long step backward in systems design. Fundamentally it turns Windows itself into more of a multi-processing GUI and less of an operating system while embedding more and more of the real operating system elements into the hardware flash memory and BIOS.
You can see Microsoft's point: they get convergence, digital media rights management, and significantly reduced processor dependence in one step, but the cost to users in application compatibility and usage freedom is going to make past transitions appear trivial by comparison.