Better on the inside: under the hood of Windows 8

Windows 8's most obviousand most divisivenew 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 thisaccess
the Pictures library, say, or connect to the network as either a client
or a serverit 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 manifestnetwork access, library access, and so onand 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 environmentthey 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.
Tick tock
Windows 8 has a few tricks up its sleeve even for systems that don't
support fancy new stuff like Connected Standby. In a move that can't
have come soon enough, it gets rid of the kernel tick.
In the olden days, all kernels ticked. The kernel would schedule a
regular periodic timer that would fire every few milliseconds (the
exact frequency varied from operating system to operating system;
Windows 7 uses 15.6 milliseconds) in order to do certain bookkeeping
tasks such as updating the system's internal clock and running the
process scheduler to enable multitasking. Typically, timed operationsthings like "wait 200
milliseconds for data to come in over the network connection" or "wait 50 milliseconds for this process
to terminate"would have their time delays rounded to some multiple of the tick frequency, and the
system would deal with handling the events as part of its timer tick processing.
This was very convenient to do; even primitive hardware had the ability to create these periodic timers,
and they would reliably interrupt the CPU, giving it an opportunity to do its work.
Back when processors were hot and devoid of power management there was no real reason to work any
other way. But processors these days (and for some years now) all have power management
capabilities. When they have no work to do, they can be put into various low-power modes, drastically
reducing their power consumption. The more time they can spend asleep, the less power they use, and
the longer your battery lasts.
With this kind of processor, that periodic tick is a liability. It means that even when the processor has
nothing useful to do, it will be awakened every so often, just to update a few counters and then go back
to sleep.
Recognizing the undesirable nature of constantly waking up the CPU, other operating systems have
added support for tickless kernels, also known as dynamic tick. Linux integrated support for this in
2007, and xnu, the kernel used in OS X, is also tickless.
With a tickless kernel, instead of indiscriminately making the timer fire every few milliseconds, the
kernel takes a look at all the timed events outstanding, and then sets the timer for the earliest timed
event it has to wait for. So if the shortest wait the system has to attend to is 300 milliseconds then the
timer will be set for 300 milliseconds.
This approach maximizes the amount of time the processor can remain asleep, but requires kernel
changes to make sure that the bookkeeping that was previously done each tick is still handled properly.
With Windows 8, Microsoft has done that work. In Windows 7, a processor could never be idle for
more than 15.6 milliseconds, and occasionally was idle for even less. Microsoft measured the idle
periods of an idle PC with the screen on, and 35 percent of them were longer than 100 milliseconds.
Enlarge / This histogram shows the di!erent idle times experienced by processors in Windows 7 and Windows 8. Notice that Windows 7
can never idle the processor for longer than 15.6 milliseconds.
Microsoft
Helping maximize these gains, Windows 8 makes greater use of coalesced timers, which were
introduced in Windows 7. The difference between a coalesced timer and a regular timer is that a
regular timer specifies only a time to wait; a coalesced timer specifies a time to wait, and an acceptable
delay. When several coalesced timers are due at about the same time, the system will delay the earlier
timers so that they can run at the same time as the later ones, batching them up and letting the system
remain idle for longer.
Windows 8 uses more coalescing, where possible. It also introduces a new API to make it easier to
replace certain regular timers with coalesced ones. As a result, Office 2013 now takes advantage of
coalesced timers when it can as part of its tuning for low power.
Securing memory
Software bugs are, alas, a fact of life. Some kinds of software bug can
be exploited by hackers, a problem that has plagued the world of
computing for literally decades. Modern operating systems therefore
provide mitigations for software bugs, employing various techniques
to try to make the bugs harder to exploit.
This results in a cat-and-mouse game. As each new mitigation
strategy is introduced, exploits have to become more cunning to
bypass them.
Windows' first major mitigation technique was Data Execution Prevention, DEP, introduced in
Windows XP Service Pack 2. Before DEP, the memory belonging to a process was usually readable,
writable, and executable. After DEP, the memory was just readable and writable; the processor would
refuse to execute it. This meant that even if a hacker could use a software bug to inject code into a
process, his code would not be executable.
Hackers worked around DEP with a technique known as return-to-libc. Hackers still take advantage of
software bugs to inject their malicious code into the process, but instead of trying to execute their code
directly, they instead execute a system library function, typically using that function to mark the code
they injected as being executable. After that, they can run the injected code.
In response, Microsoft introduced something called ASLR, Address Space Layout Randomization, in
Windows Vista. With ASLR, system libraries are loaded into random memory locations each time the
system is booted. This hurts the hackerssince they don't know where those system library functions
will be stored in memory, they can now no longer easily execute them.
ASLR randomizes the location of libraries within a process' memory space.
Microsoft
ASLR is an important protection. Without it, DEP can usually be bypassed quite easily. Unfortunately,
ASLR isn't perfect. It has a few issues that have enabled hackers to defeat it and break into people's
computers. The biggest single problem is that ASLR is opt-in. ASLR can only be applied to libraries
(DLLs) that are compatible with ASLR. DLLs indicate that they're compatible by setting one of their
own internal file structures to a particular value.
If the DLL is built with a very old version of Microsoft's Visual Studio development environment, one
that pre-dates ASLR, then it won't claim to be compatible with ASLR. Most DLLs are compatible with
ASLR, even if they don't claim to be, because being loaded at a random place in memory is something
that DLLs always have to be able to cope with, even without ASLR. Although each DLL has a preferred
spot in memory where it would like to be loaded, sometimes that preferred spot is already taken, so the
DLL has to be put elsewhere. But if the DLL doesn't claim to be compatible with ASLR, traditionally
Windows refrained from randomizing it, just in case it was one of those rare few that really weren't
compatible.
This is a problem, because even having a single library loaded into a predictable place in memory can
give hackers the foothold they need to break ASLR and hence break DEP. Over the years, there have
been some high profile examples of DLLs that don't indicate that they're compatible with ASLR; old
versions of Flash, old versions of Java, and even old versions of .NET. Machines have been exploited as
a result.
ForceASLR
Windows 8 has a feature called ForceASLR that counteracts this. When ForceASLR is enabled for a
process, Windows will try to load all DLLs at a random location, even the ones that don't claim to be
compatible. There are still some DLLs that can escape this randomization, however: DLLs that can
only be loaded into their preferred memory spot, which lack the information required to move them
around should that spot be taken. ForceASLR has two options for these DLLs; the weak option allows
them to load at their preferred location anyway, the strong option simply refuses to load them entirely.
ForceASLR is useful enough (and simple enough) that Microsoft actually backported it to Windows 7
offering it as an update for the older operating system.
Windows 8 has other ASLR changes that weren't backported, however, that improve other aspects of
ASLR. Windows' original ASLR was designed when 32-bit systems were still prevalent, and it has some
limitations as a result. 32-bit processes only have 4GB of memory available to them, of which 2GB is
usually off-limits. Every DLL they load, every piece of memory they allocate and use all have to fit into
the 2GB that are left over.
Most applications like to have lots of contiguous memory available; it makes things much easier when
an application that needs a 1GB chunk of memory can allocate it in a single block. This means that
ASLR has some constraints; it needs to be random, but it can't be too random. It wouldn't do to spread
DLLs throughout the entire 2GB of memory that the application has to use, because it would prevent
the application from making large contiguous allocations.
As a result, ASLR can only randomize within certain limits. Instead of being able to load libraries at a
couple of billion possible locations across a couple of billion bytes of memory, it picks from a few
hundred or a few thousand locations that are all relatively close to one another.
64-bit computing is now abundant, and Windows Vista ushered in much greater usage of 64-bit
Windows. 64-bit processes aren't constrained to 2GB of addresses; they have a theoretical 9 exabytes
(9!10
18
) bytes to play with. However, even in 64-bit Windows, ASLR used levels of randomness that
were more appropriate to a 32-bit process; it didn't take advantage of the huge playing field that 64-bit
enables.
64-bit Windows 8 processes use a new feature called High Entropy ASLR (HEASLR) to overcome this.
HEASLR cranks up the randomness: it allows ASLR to randomize locations across a terabyte of
memory, making it much harder to predict.
HEASLR
HEASLR, like ASLR before it, unfortunately requires applications to opt in: DLLs have to tell the
system that they support HEASLR, and if they don't, they'll get the old level of randomization. And
while Visual Studio defaults to enabling regular ASLR, HEASLR defaults to off, so developers will have
to explicitly opt in.
Windows 8's ASLR also randomizes more things than Windows 7's does. Libraries are the main thing
to be randomized, because they're the main point of attack, but they're not the only thing. In the past,
Adobe Reader and Chrome have both had their sandbox mechanisms attacked because attackers took
advantage of their memory allocations being predictable. Windows 8 now applies randomization to
certain low-level memory allocation functions, preventing this kind of prediction.
While some of these changes are opt-in, Internet Explorer is one of the applications that takes
advantage of the full set. Combined with the sandboxing, it should result in a browser that's much
harder for bad guys to break into. And as with the sandboxing, we can hope to see other browsers and
high-risk applications pick up support for the new, stronger ASLR.
Windows 8 system services also enable HEASLR, hardening them against network attacks. Metro apps
also have HEASLR enabled as well as ForceASLR.
The randomization part of ASLR may be a little better, too: when used with Intel Ivy Bridge processors,
Windows 8 takes advantage of a new random number generator built into the processor to decide on
the random addresses it uses. On systems without Ivy Bridge, ASLR is still randomized according to
things like the system clock, which is less effective.
Better DEP, too
Protection provided by the CPU is an important part of these exploit
mitigation techniques. DEP is fundamentally a hardware feature
(though Windows does have a kind of weak emulated software DEP,
Windows 8 makes hardware DEP support mandatory for the first
time), with the processor itself trapping attempts to execute memory
that isn't marked as being executable.
Intel's latest Ivy Bridge processors include a new refinement to DEP
that's designed to make bugs in the operating system kernel harder to exploit. As previously
mentioned, the memory available to each 32-bit process, a total of 4GB, is usually split, with 2GB
belonging to the process itself, and 2GB belonging to the kernel. 64-bit processes have a similar split,
with 9 exabytes (EB) belonging to the process, and 9EB belonging to the kernel (though you can't, on
current processors, actually use all 9EB; it would require acres of RAM, in any case).
Prior to Ivy Bridge, the split was, in a sense, "one way." The process can read, write, and execute the
half of memory that it owns, but the half that belongs to the kernel is off-limits. The kernel, however,
can read, write, and execute both halves. This is very handy for attackers wishing to exploit kernel
bugs. The general desire with kernel bugs is to make the kernel, which is highly privileged, run attack
code specified by the attacker; that code then runs with the kernel's privileges, and so can be used to
gain complete access to the system.
When exploiting a kernel bug, the attacker normally has control over a process. They can store their
exploit code in the process' memory, mark it as executable (to make DEP happy) and then trick the
kernel into executing it. This works precisely because the kernel can access all the process' half of the
memory and can execute it.
This is not ideal. While the kernel does need to be able to read and write the process' half of the
memory (so that it can pass data back and forth), it never has any practical need to execute itsuch
behavior is only ever useful for exploits. It's just that traditionally it could, because the kernel is
virtually unrestricted in what it can do.
These attacks are more important than they ever used to be because sandboxing and similar
techniques are becoming so much more prevalent. Ten years ago, attackers could almost depend on the
fact that the Web browser was running as an Administrator with full privileges and access to the
system; there was no need to gain privileges from the kernel through subterfuge and trickery. That's
not the case today; attacking the kernel to increase privileges is an important way of escaping from
sandboxes.
Ivy Bridge has a new feature called "Supervisor Mode Execution Prevention" (SMEP) that addresses
this. When SMEP is enabled, the kernel (which runs in a privileged mode called "supervisor mode")
can no longer execute any of the process' memory. This means that the attack code, stored in the
memory half of the process, is useless.
Windows 8 supports and enables SMEP, making it harder to exploit kernel flaws in this way.
The arms race between hackers and operating system developers is a continuous one, however. If
attackers cannot put their attack code in the process' memory due to SMEP, they will look for ways to
put it into the kernel's memory instead. Windows 8 takes some preventative measures here, too. In
prior versions of Windows, the kernel's memory was generally marked as being executable; in other
words, it essentially had no DEP protection. If an attacker could get the kernel to copy their attack code
into the kernel's portion of memory then they didn't have to worry about ensuring that the code was
executable; the kernel already did that for them.
In Windows 8, that's no longer the case; the kernel now allocates and uses memory that's marked as
non-executable, and uses non-executable for most buffers and other data structures. The result is a
kernel that's harder to attack and harder to exploit (though unfortunately, not impossible, as there are
still some operating system buffers that use executable memory, and third-party drivers may similarly
allocate executable memory).
Proactive defense
Windows 8 also takes steps toward eliminating access to a kernel component that has been a consistent
source of trouble over the years. win32k.sys is a Windows driver that's responsible for providing core
services to GUI applications; it implements portions of both USER, the Windows component that
handles the creation and manipulation of windows, and GDI, Windows' ancient 2D graphics API. Once
upon a time, win32k.sys didn't reside in the kernel; prior to Windows NT 4, it was a non-kernel
component. However, to improve GDI performance in Windows NT 4, it got moved into the kernel,
and it has remained there ever since.
win32k.sys includes all sorts of complicated things, and these complicated things have historically had
security flaws in them. The Duqu trojan, for example, exploited a win32k.sys font parsing bug.
Windows 8 does not reverse Windows NT 4's design change (at this point in time, it's hard to see
Microsoft ever undoing that particular alteration), but it does take some steps to make them a bit
harder to exploit. In Windows 8, processes can be barred from having access to any win32k.sys
features. The result? No matter what win32k.sys bugs crop up in the future, attacks on those processes
won't be able to take advantage.
Slimline memory usage
In another one of those "motivated by the needs of tablets, but useful for everyone" features, Windows
8 is designed to use less memory than its predecessors. Slightly
surprisingly, one of the techniques Microsoft is using to make
Windows work better on small, low-memory machines is also
important for huge, high-memory servers running dozens of virtual
machines: memory deduplication.
In Windows (and every other operating system that supports virtual
memory, which is to say, every operating system anyone cares about)
memory is divided into, and allocated in units of, pages that are typically 4,096 bytes in size. All the
memory manipulation that the kernel handleswriting data out to the page file, reading it back in,
reading executables and DLLs, allocating new memoryis performed in page-sized chunks.
Information about pages, such as whereabouts in physical memory a page exists, or whether it can be
read, written, or executed, is managed by the processor and operating system working in tandem,
using data structures called page tables.
This infrastructure is fundamental to modern operating systems, and it allows all sorts of clever
trickery. For example, Windows can take a file on disk and "memory map" it. When a file is memory
mapped then pages of memory belonging to an application have a 1:1 correspondence with the file on
disk. As the application reads and writes to pages in memory, behind the scenes the operating system
reads and writes the corresponding parts of the file. Windows uses this for loading executables and
DLLs, for example. Instead of reading in the entire executable to start a program, it just memory maps
it; as different parts of the executable are needed, they get read from disk. Portions of the executable
that correspond to features that you don't actually use never get read from memory, and hence never
have to get read from disk.
Another trick is that it allows sharing. One piece of physical memory can be allocated to pages, and this
page can then be assigned to multiple applications simultaneously. This is commonly used with
memory mapped files: if you run, say, Notepad twice, you'll have two Notepad processes, but within
each process, the pages that contain notepad.exe will actually be shared, since they correspond to the
same file on disk, and must have the same contents at all times.
Executables are an easy case, however. Although they get read and executed, they (almost never) get
written. There's no possibility that one Notepad process might try to alter notepad.exe, for example,
and in fact, the pages are protected from writes; the process couldn't alter notepad.exe even if it
wanted to.
This is not, however, mandatory. Shared pages can be made writable. Sometimes, you want those
writes to be visible to every process that has the shared page. Other times you do not. Both options are
possible. In the former case, there's nothing special to do; processes can write to the page, changing the
value in physical memory, and they'll all see the same thing. In the latter case, a system called copy-on-
write (COW) is used. Whenever a process tries to write to a shared page, the operating system makes a
private, unshared copy of that page, and uses that private copy instead of the shared copy. The private
copy can then be written to willy-nilly.
Traditionally, Windows has only used shared pages extensively for these memory mapped files,
whether they be executables and DLLs, data files, or portions of the pagefile.
Windows 8 extends the use of shared pages to allow any pages that just happen to be identical to be
shared. It periodically sweeps through all the memory in the system, identifies pages that have the
same contents, makes them shared, and frees up some physical memory. If one process should then try
to modify the newly shared page, Windows uses COW.
It might seem a little surprising for different applications to have much memory duplicated. This
memory deduplication technique first came to prominence in VMware. When running a bunch of
virtual machines all running the same operating system there can be a lot of duplication. For example,
each instance of the operating system will be using the same kernel, so the pages corresponding to the
kernel will be identical, and hence ripe candidates for sharing.
Desktop users might do a bit of virtualization too, but the real scenario for memory deduplication on
desktops and tablets is deduplicating wasteful or unused memory allocations. It's not unusual for
applications to allocate a chunk of memory, fill it with some placeholder value (such as all zeroes), and
then not actually use it, or use only a portion of it. These memory pages can be deduplicated, reducing
the impact of this unused memory.
It's a little hard to know just how much impact this deduplication has. It will depend heavily on which
applications you run, and what you actually do with them. Some kinds of application are more prone to
this over-allocation than others; for example, it's a common trait of systems that use garbage-collected
memory. Microsoft claims that it can lead to savings of tens or even hundreds of megabytes. If nothing
else, it'll be very welcome for Hyper-V users.
A better operating system for all
Beneath the user interface, Windows 8 is in almost all regards a more efficient, more secure, more
reliable operating system. From high-speed, hibernation-powered booting to Connected Standby and a
tickless kernel, it takes the solid Windows 7 foundation and makes things better.