To read all comments associated with this story, please click here.
The kernel, drivers, and all of the apps in the package are 64-bit. What's not pure about it? In terms of third-party apps, most don't need 64-bit versions. They run on x64 Windows just fine via WOW64.
Depending on your workload, 32-bit Windows may be fine, but some people benefit from the larger available address space (even when running 32-bit apps -- particularly some games).
The NT kernel indeed allows for subsystems (up until Windows 2000, for instance, it had an os/2 subsystem), but would you really want to run the entirety of win32 in an NT subsystem?
One of the prime points in these two articles of mine is that you really do! not! want! to ship/run the current Windows userland, because it is a mess - if you move it to a subsystem, you do just that: you move it to a subsystem. You're just moving it around, you're not sandboxing or isolating it.
The NT kernel indeed allows for subsystems (up until Windows 2000, for instance, it had an os/2 subsystem), but would you really want to run the entirety of win32 in an NT subsystem?
Actually, Win32 as it is, IS a subsystem in the very sense of the NT definition. Maybe with the years, they spaghetti coded some stuff, but that's being unwired for quite some time now (been said a whole lot during the Vista development, and Traut said it in his presentation).
One of the prime points in these two articles of mine is that you really do! not! want! to ship/run the current Windows userland, because it is a mess - if you move it to a subsystem, you do just that: you move it to a subsystem. You're just moving it around, you're not sandboxing or isolating it.
If it runs in a tailored VM or in a controlled subsystem (using resource virtualization a la UAC), where's the difference? Latter is easier on the total system.
As said earlier, the best way to implement this IMO would be using a construct like Solaris Zones, where there's hard partitioning inside the kernel already, running full blown operating systems (well, everything right above the kernel) inside the partitions, but using the same kernel and as such able to share resources (mostly just CPU and memory). Using a huge shim, you would be able to keep the old Win32 system running, just like Solaris can run e.g. the whole unmodified Ubuntu userland using a syscall translator in a zone.
VMs really aren't a solution for this, because they're too static and have a huge footprint (memory). To make them more flexible in that regard, the guest operating system would have to be able to deal with fluctuating memory sizes. I don't see that coming anytime soon, at least not automated, because different systems deal with memory pressure in different ways, resulting in a memory scheduling clusterf--k.
WoW has been around since the earliest releases of Windows NT 3.51. There were several "personalities", as they were called, released with NT 3.51:
- Win16
- Win32
- OS/2
- Posix
- probably more, but that's all I can remember off the top of my head
The OS/2 personality was dropped with Windows 2000, the Posix subsystem was "replaced" with Services for Unix, and Win64 was added.
This is not a new concept, and was one of the main selling points of Windows NT back in the day.





Member since:
2006-03-20
I keep posting it whenever this topic is being talked about.
WOW64 is proof, shipped with any 64bit Windows, that it's entirely possible to run two different userlands (more like subsystems) on the same kernel. There's a full 32bit subsystem installed to run any 32bit application, and apart from messaging, the 32bit subsystems runs completely on its own, only sharing the kernel as common code.
Nothing speaks against a completely new main subsystem, keep the old one running side by side for "legacy" applications. Glue put where needed (i.e. windowing).
Alternatively, Microsoft could take a clue from Solaris Zones, if there's a more heavy-handed approach needed (quasi full hosting of an operating system), which is still lightweight in regards to resource sharing.