Windows 8's most obvious—and most divisive—new feature is its user interface. However, it would be a mistake to think that the user interface is the only thing that's new in Windows 8: there's a lot that's changed behind the scenes, too.

Just as is the case with the user interface, many of the improvements made to the Windows 8 core are motivated by Microsoft's desire to transform Windows into an effective tablet operating system. Even those of us with no interest at all in tablets can stand to take advantage of these changes, however. For example, Windows 8 is more power efficient and uses less memory than Windows 7; while such work is critical to getting the software to run well on low-memory tablets with all-day battery life, it's equally advantageous for laptop users.

The biggest single piece of technology that is new to Windows 8 is, however, squarely Metro focused: it's a large set of libraries and components called WinRT. I've already written extensively about what WinRT is, so I won't be getting into that here, but there are system capabilities that WinRT apps can use (or are forced to use) that are interesting in their own right.

Playing in the sandbox

First up is sandboxing. Metro-style apps are all sandboxed: by default, each app can only read from and write to its own private storage area. If the app needs to do anything more than this—access the Pictures library, say, or connect to the network as either a client or a server—it must explicitly indicate that it needs these extra capabilities in something called a manifest. This prevents apps from being able to read each other's files, documents that you haven't explicitly granted them permission to read, and so on. This serves two purposes; it helps safeguard user privacy, instilling greater confidence in apps downloaded from the store, and it also reduces the impact of security flaws in those apps.

These sandboxes are enforced by a new Windows 8 feature called AppContainers, which in turn builds on a feature introduced in Windows Vista, called integrity levels. Before integrity levels, access to files and registry keys on Windows was governed solely by the user identity. Every file and registry key has an access control list (ACL) which describes which users and groups can perform what operations to those files and registry keys. For example, an ACL on a file might say that User A can read the file, User B can read and write the file, and Group C can read, write, and delete the file. Every process running with User B's identity would have the same access to that file: read and write.

Integrity levels created a system to give processes all running with the same user identity different levels of access to the system. Each process has not just the user identity, but also an integrity level, denoting the trust given to the process. Web browsers, for example, would be given low integrity, because they're not especially trusted (because they are so often attacked and exploited by malicious Web pages). A normal process such as Notepad might be given medium integrity, because it's relatively unlikely to be attacked. An installer or setup program might be given high integrity, because it's trusted to update pieces of system configuration. There is also an untrusted integrity, that's even lower than low, and a system integrity, that's even higher than high.

Every file and registry key on the system is tagged with an integrity level, which specifies the minimum level required to write the file. Reads are (almost) always allowed. Temporary directories, for example, might be tagged with low integrity, allowing even Web browsers to use them. System directories will be tagged with high integrity, preventing modification by low and medium integrity processes.

This integrity level system was instrumental in User Account Control (UAC), the confirmation prompts also introduced with Windows Vista. With UAC enabled, even an Administrator account normally runs processes with only medium integrity, and hence preventing modification of system files. Clicking on a UAC prompt creates a process with high integrity. This is why you need to perform UAC elevation before you can modify system files.

AppContainers introduce an additional integrity level, called simply AppContainer. AppContainer is even more restricted than low integrity. AppContainer blocks both reads as well as writes. Unlike low integrity, it isn't a simple tag. When each Metro app is installed, the system examines the capabilities that the app says it needs in its manifest—network access, library access, and so on—and constructs a unique AppContainer security identifier based on those capabilities. When the app is run, it not only has the AppContainer integrity level applied; it also has this security identifier applied.

Windows then uses this information to perform extra validation whenever the process tries to perform a restricted operation, such as opening a file or making a network connection. It uses the information in the security identifier to determine whether to allow the operation. For example, only if the security identifier indicates that the process has "access the Photos library" capability will the system allow the app to open files from the Photos library.

This system allows Windows to exercise tight control over Metro applications. It removes access to almost the entire system, letting them see only a tiny selection of files.

Although the sandboxing AppContainer mechanism is primarily used by Metro apps, it's not actually restricted to them. There's an API and documentation for it, and regular applications, even on the desktop, can use it. The first application to actually do so is Internet Explorer 10. Internet Explorer has two guises in Windows 8; a desktop guise, and a Metro guise. The Metro guise puts all of its tabs in AppContainers, so if a malicious attack is made, it will be quite a bit harder for the attacker to break out and damage the system.

Desktop Internet Explorer doesn't put its tabs in AppContainers by default, because most plugins and extensions can't cope with such a limited environment—they need to at least be able to read the hard disk, so need at least low integrity. However, you can opt in to a new mode called Enhanced Protected Mode that will put each tab of the desktop browser into a sandbox. If you come across a page that needs an extension, Internet Explorer will offer to reload the page without the sandbox.

Mozilla has investigated the AppContainer mechanism for its own Metro browser so Internet Explorer is unlikely to be the sole browser to offer this security. Other software such as Adobe Reader also uses sandboxing, and over time could take advantage of this Windows 8 feature.

Power preservation

Preserving battery life is one of the key goals for Metro applications. Unlike desktop applications, Metro applications aren't in general allowed to run in the background; unless you're actively looking at a Metro application, Windows suspends it after a few seconds. If memory becomes low, Windows will quietly terminate the app. Switching back to the app, whether it was suspended or terminated, resumes it.

To ensure that apps don't lose their state when terminated, they're given an opportunity to save any necessarily information just before they get suspended. They can then reload this information when resumed, allowing the user to continue using the app without any interruption.

Apps that need to do work in the background without that work being interrupted by suspension and resumption can register background tasks. These background tasks are subject to tight CPU and network usage constraints to ensure they don't interfere with the machine's performance.

In and of itself, that's not too special. It's just suspending and resuming some processes. However, Windows 8 takes this to another level with a feature called Connected Standby.

Connected Standby allows Windows to take process suspension to the next level, pausing not just apps but the entire machine, while still allowing these background tasks to run.

With Connected Standby, the operating system can put itself in an extremely low-power suspended state, but without losing network connectivity. Whenever some network activity occurs, it will wake up just enough to handle that activity, before going back to sleep. With Connected Standby, a system can receive all the power savings and long lifetime of standby mode, but still fetch new e-mail as it arrives, respond to VoIP calls, or whatever else it might take to keep up-to-date.

Connected Standby isn't a pure software feature. It requires network adaptors to support a special suspend mode, whereby they remain connected to the network, but do not need the CPU to poll them periodically (this is particularly an issue for USB network adaptors). It also requires a processor that can operate without a fan, a solid state disk, and the system firmware to advertise support of a very-low-power idle mode.

These capabilities, especially the ability to operate without a fan, are rare, and presently restricted to certain system-on-chip (SoC) machines, such as Microsoft's Surface. The passive cooling requirement makes it unlikely that we'd ever see, for example, Connected Standby support on an Ivy Bridge machine, but none of the requirements actually require the use of SoCs.

When a system supports Connected Standby, those Metro background tasks can fire up if necessary even when the system is suspended. Programs such as Skype listen out for network activity in a background task. The system goes to sleep, but if the Skype connection should start receiving data due to an incoming call or instant message, the network adaptor wakes the CPU and lets the Skype task start handling the data. Skype might then update its indicator on the lock screen to show that you've got a new IM or missed a call, or it could sound the speaker to alert you to the call.

Connected Standby allows machines to sleep for days at a time while still remaining up-to-date. The only wrinkle is that at the moment, only Metro apps can register background tasks to run during Connected Standby. Desktop applications get completely suspended. So while the Metro Mail app might be able to keep itself up-to-date even with the machine almost "turned off," Outlook cannot.