Top 10 New Features in Windows Server 2008
#7: Kernel Transaction Manager. This is a feature which developers can take advantage of, which could greatly reduce, if not eliminate, one of the most frequent causes of System Registry and file system corruption: multiple threads seeking access to the same resource.
In a formal database, a set of instructed changes is stored in memory, in sequence, and then "committed" all at once as a formal transaction. This way, other users aren't given a snapshot of the database in the process of being changed - the changes appear to happen all at once. This feature is finally being utilized in the System Registry of both Vista and Windows Server 2008.
"The Kernel Transaction Manager [intends] to make it very easy to do a lot of error recovery, virtually transparently," Microsoft software engineer Mark Russinovich explained. "The way they've done this is with the [KTM] acting as a transaction manager that transaction clients can plug into. Those transaction clients can be third-party clients that want to initiate transactions on resources that are managed by Transaction Resource Manager - those resource managers can be third-party or built into the system."
#6: SMB2 network file system. Long, long ago, SMB was adopted as the network file system for Windows. While it was an adequate choice at the time, Russinovich believes, "SMB has kind of outlived its life as a scalable, high-performance network file system."
So SMB2 finally replaces it. With media files having attained astronomical sizes, servers need to be able to deal with them expeditiously. Russinovich noted that in internal tests, SMB2 on media servers delivered thirty to forty times faster file system performance than Windows Server 2003. He repeated the figure to make certain we realized he meant a 4000% boost.
#5: Address Space Load Randomization (ASLR) Perhaps one of the most controversial added features already, especially since its debut in Vista, ASLR makes certain that no two subsequent instances of an operating system load the same system drivers in the same place in memory each time.
Malware, Mark Russinovich described it (as only he can), is essentially a blob of code that refuses to be supported by standard system services. "Because it's isn't actually loaded the way a normal process is, it would never link with the operating system services that it might want to use," he described. "So if it wants to do anything with the OS like drop a file onto your disk, it's got to know where those operating system services live.
"The way that malware authors have worked around this chicken-and-egg kind of situation," he continued, "is, because Windows didn't previously randomize load addresses, that meant that if they wanted to call something in KERNEL32.DLL, KERNEL32.DLL on Service Pack 2 will always load in the same location in memory, on a 32-bit system. Every time the system boots, regardless of whose machine you're looking at. That made it possible for them to just generate tables of where functions were located."
Now, with each system service likely to occupy one of 256 randomly selected locations in memory, offset by plus or minus 16 MB of randomized address space, the odds of malware being able to locate a system service on its own have increased from elementary to astronomical.
"This slide...this being a keynote, the marketing people had to make a pass through the deck. And this thing is technical, which is a little bit different from what they're used to, they didn't understand any of the slides. But they still wanted to feel like they were adding value, so they threw this slide in. And of course, I don't understand this slide. But I hope you like it." - Mark Russinovich, Microsoft technical fellow
#4: Windows Hardware Error Architecture (WHEA). That's right, Microsoft has actually standardized the error - more accurately, the protocol by which applications report to the system what errors they have uncovered. You'd think this would already have been done.
"One of the problems facing error reporting is that there's so many different ways that devices report errors," remarked Russinovich. "There's no standardization across the hardware ecosystem. So that made it very difficult to write an application, up to now, that can aggregate all these different error sources and present them in a unified way. It means a lot of specific code for each of these types of sources, and it makes it very hard for any one application to deliver you a good error diagnostic and management interface."
Now, with hardware-oriented errors all being reported using the same socketed interface, third-party software can conceivably mitigate and manage problems, reopening a viable software market category for management tools.
Next: Windows sans windows...