Flawed Student Version of Windows 7 Now Fixed

"Basically it loads a 32 bit interpreter layer, and performs complex API translation..."

On x86 hardware, WOW64 just switches the processor from 64-bit native mode (the fastest mode for x86 hardware) to the slower 32-bit/64-bit hybrid mode (the mode that OS X runs full-time, unless you are actually able to boot the 64-bit kernel).

Upgrading from 32-bit to 64-bit isn't really a good idea. Let's say you install an app before the upgrade and the app, detecting you are running 32-bit, installs a 32-bit shell extension for Windows Explorer (e.g. a Winzip context menu extension). You then upgrade to 64-bit Windows; the app itself remains but the context menu extension doesn't work. A user would be confused and blame Windows 7 for breaking the context menu.

Doing a fresh install of the app would allow it to detect it's on a 64-bit OS and install the 64-bit version of its shell extension.

Another issue is that on 32-bit, the folder for your apps is "Program Files", however when upgrading to 64-bit they would be moved to "Program Files (x86)". Programs that hard-coded somewhere (in a config file for example) the location they were installed to, will now be broken.

Behind the scenes, Windows upgrades (as of Vista/7) are essentially fresh installs of the OS image, that then try to carry over the existing programs, accounts, and settings. What Windows really needs is a good application model that would solve all of these problems.

"when MS successfuly did the upgrade from 16-bit windows 3.0 to 32-bit windows 95"

But that's the point. 16 bit Windows 3.1 to Windows 95 was possible because Windows 95 wasn't a 32-bit OS. It mixed 16 bit and 32 bit dlls and had absolutely no isolation.

Operating systems that mix are fundamentally inefficient. When a CPU switches between CPU states (16, 32, and 64-bit ones) it has to flush the pipeline of all current in-flight commands.

So if you alternate between 32 and 64 constantly, you essentially halve your PC performance because the CPU is constantly changing state. The OS kernel tries to mitigate this by sending sequences of similar code, or binding bit-depth-similar applications to the same CPUs in multi core systems, and the CPU scheduler tries to mitigate this by rearranging commands before they are pushed into the pipeline.

9x wasted a lot of clock cycles because pretty much anything could be in-flight (thus the CPU was constantly flipping states), plus priority and scheduling algorithms were sub-par compared to current day. Plus it made protecting memory miserable, etc.

The added efficiency that NT-based-OS (Xp, Vista, 7) get from this method allows them to do a lot of other robust things without taking a performance hit compared to the competition. This is also why SL is better than the prior OSX. There was a lot less "bit purity" in prior versions, as a result you could force CPU state changes much more frequently. They still allow a bit-mix, but they've remedied a lot of that problem in regards to core components. However, since OSX wasn't built from the ground up with the intent of isolating similar execution, they're gradually evolving to a cleaner architecture. Microsoft basically "started over" with NT rather than evolved what they had.

Christopher, all your explanation is invalid when you think your alleged obstacles were there when MS successfuly did the upgrade from 16-bit windows 3.0 to 32-bit windows 95: all these dll mixtures, all software problems etc.

"And now, why can't we expect such an upgrade path from Microsoft? Is it a rocket science?"

Well, the thing is that Win 95 included 16 and 32 bit code in its core, which is why it was phenomenally unstable. x64 Windows does not contain *any* 32-bit code (other than modules needed to support 32, and some 32-bit applications, ie, etc). Whenever you run a 32-bit app on 64-bit windows, anything 32 gets loaded through a virtual machine called WOW64 (windows on windows). Basically it loads a 32 bit interpreter layer, and performs complex API translation... None of the code runs with the 64bit layer. That's why driver support was vastly worse to begin with, since you can't include 32-bit drivers on a 64-bit system. It doesn't virtualize the hardware layer since that's inefficient and asking for all sorts of problems.

If you actually upgraded, you would have a dll mix between 32 and 64, and lots of things would likely stop working correctly because of all the bit disparities. Not to mention, if MS wanted to do a proper upgrade, the disc would need to contain a 64-bit version of every dll ever made.

MS did this for the basis of stability since the OS isn't mixed-mode like some competing solutions. NT has always been this way, and that's partly why it's a brick compared to 9x. Over the years they've done a lot of work making NT even more robust, but the first choice was total isolation of bit-layers.

In theory, yes, you might be able to upgrade the OS. But the likelihood of all the applications working properly would be below the threshold for a boxed retail product. It would just make them look bad. Better to write an app that helps you migrate, rather than try to do it directly.