Okay, so it’s fairly obvious that you can only run 32-bit (x86) windows on a 32-bit processor, but of course a 64-bit processor would run both an x86 and an x64 OS. So how do you find out which “bit-version” you’re actually running? Easy. WinKey+R (to bring up the run box) and then type “msinfo32”.
The “System Type” line in the right-hand pane (when clicked on to “System Summary” on the left) will tell you the bit-version; so, for example, the VMWare PC I’m typing into now reports it’s an x64-based PC, but my other VM is an x86 Windows XP PC (and they’re both running on an x64 version of Vista Business with VMWare 7)
So, regardless of what your processor is capable of, you’re limited to whatever architecture of Windows you’re running; you can’t install 64-bit Office if your version of Windows is 32-bit, even if your processor can support x64 programs.
Just a quick word of warning; be careful when copying a Windows Vista/ 7 system drive wholesale with robocopy! I’ve had a strange issue this week when trying to backup my work’s laptop drive in another PC (faulty LCD panel so I can’t see anything to back it up on the laptop). The issue seems to revolve around the “Users” folder and the pseudo-“Documents and Settings” junction point; basically, it started copying data off the host PC and more bizarrely, created huge numbers of nested “Application Data” folders underneath certain user profiles. After knocking up a quick-‘n’-dirty batch file to sort out the “Application Data” folder problem:
attrib -r -h -s * /S /D
IF EXIST “Application Data” MOVE “Application Data” a
I could eventually delete all user profiles (the paths were too long before) and then re-run robocopy with the following switches:
/XF hiberfil.sys pagefile.sys
/XD “F:\Documents and Settings” “F:\Users” “F:\ProgramData” “F:\$Recycle.bin”
(quote marks are very important, especially where there are spaces in the names).
After re-running like this, I had most of the drive and then simply backed up the user profiles I was interested in individually.