I've been running the 64-bit version of Windows 7 RC since June.
It's been quite painless on the whole.
One wrinkle that I ran into was with some batchfiles which
launch applications in %ProgramFiles% (normally C:\Program Files).
Due to the magic WOW64 redirector, 32-bit applications
are actually installed into %ProgramFiles(x86)%—normally C:\Program Files (x86)—instead of %ProgramFiles%.
This is transparent to the 32-bit applications,
which think they're running in %ProgramFiles% (C:\Program Files).
However, the cmd.exe shell is 64-bit
(unless you make a special effort to run the 32-bit cmd.exe in SysWOW64),
so batchfiles see the 64-bit %ProgramFiles% which contains 64-bit applications.
Hence, a batchfile that launches an installed 32-bit application on Win64
must use %ProgramFiles(x86)%, not %ProgramFiles%.
It sounds trivial to have a batchfile detect
which flavor of %ProgramFiles% it should use,
but the parentheses in the environment variable name make it tricky to parse.
On earlier versions of Win64, the environment variable was called %ProgramFilesx86%.
Presumably they added the strange parentheses into the variable name
because the directory name always included them.
Here's a tiny batchfile that will launch the 32-bit DiffMerge
correctly on both Win64 and Win32 platforms.
@if not "[%ProgramFiles(x86)%]"=="" set _pf=%ProgramFiles(x86)%
@start "" /b "%_pf%\SourceGear\DiffMerge\DiffMerge.exe" %*
I long ago found that the safest way to test environment variables
whose values may include spaces, is to surround them with
both double quotes and square brackets.