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 ap­pli­ca­tions in %Pro­gram­Files% (normally C:\Program Files). Due to the magic WOW64 redirector, 32-bit ap­pli­ca­tions are actually installed into %Pro­gram­Files(x86)%—normally C:\Program Files (x86)—instead of %Pro­gram­Files%. This is trans­par­ent to the 32-bit ap­pli­ca­tions, which think they’re running in %Pro­gram­Files% (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 %Pro­gram­Files% which contains 64-bit ap­pli­ca­tions.

Hence, a batchfile that launches an installed 32-bit ap­pli­ca­tion on Win64 must use %Pro­gram­Files(x86)%, not %Pro­gram­Files%.

It sounds trivial to have a batchfile detect which flavor of %Pro­gram­Files% it should use, but the paren­the­ses in the en­vi­ron­ment variable name make it tricky to parse. On earlier versions of Win64, the en­vi­ron­ment variable was called %Pro­gram­Filesx86%. Presumably they added the strange paren­the­ses 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.

@setlocal
@set _pf=%ProgramFiles%
@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 en­vi­ron­ment variables whose values may include spaces, is to surround them with both double quotes and square brackets.