Reader Comments

All this might have been avoided if M$ had not made upgrading from XP to Windows 7 not possible. Is punishing people for skipping Vista really more important than encouraging upgrades to Windows 7?

"It's unclear why they made such a bone-headed mistake." Maybe they were too busy planning launch parties. ;-) Seriously, though, considering all the problems they had with Vista, if this is the worst that happens with the "7" launch it's really no big deal, eh?

"Is punishing people for skipping Vista really more important than encouraging upgrades to Windows 7?" No, but opting to not support an in-place upgrade that could result in an unstable system is a better choice for the long term.

Paul, you think it is fair for Microsoft not to allow upgrades from 32 bit products to 64 bit upgrades. It is not fair, it is not normal, and it is not a thing that cannot be overcome. Microsoft showed it 14 years ago when it introduced Windows 95, a 32-bit OS which can upgrade 16-bit Windows 3.0. And now, why can't we expect such an upgrade path from Microsoft? Is it a rocket science?

This is what you get when you sell so many versions of the same product. Heaven forbid Microsoft has a single version of the OS that contains everything one would need. Starter, home, professional, ultimate, upgrade, full install, OEM, 32 bit, 64 bit, etc. Their just released 140 page guide to Windows 7 has over 6 pages dedicated to figuring out which version is right for you.

In the long run, not allowing upgrades (but remember, still allowing migrations) from 32-bit to 64-bit, and from XP to 7 is a very solid move. The amount of issues that can occur with drivers and just plain sloppiness over years of and XP installation, the associated problems that would be caused it the future will far outweigh the current pain in performing the upgrade. After doing a 32-bit to 64-bit migration, I was honestly surprised at how well Easy Transfer went. It was amazingly slow doing the Easy Transfer backup and restore, but many more settings than I expected, even included Firefox extensions, were transferred over, making it a pretty painless process. Additionally, the reports they provide help you to remember which applications you even had on your old computer and would need to reinstall.

"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.

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.

"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.

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.

"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).