%programfiles% and %programfiles(86)

[Chris Lott]

In a command window (Windows 7, 64 bit), %programfiles% and %programfiles(86)% return different results (the first to X:\program files and the 2nd to X:\program files(86)

However, from slickrun (or from a slickrun shortcut), both go to the latter.

Is this a bug?

[Richard Grant]

That is correct. Slickrun is 32 bit, and as the launching process, %programfiles% resolves to C:\Program Files (x86)

For me on Vista 64, cmd.exe is also a 32 bit process so I get Program Files (x86) with that too. Only if I open a command prompt from a 64 bit process, such as explorer do I get C:\Program Files.

I just finished a migration of our code at work to support Vista/Win7 - the security changes weren't too bad, but by far the biggest abomination was the 64/32 divide. Microsoft really took the wrong path on this one. Don't even get me started on the changes to the registry.

[Tobias Twardon]

Thanks man.

That explained it for me.
I just copied over the directory to x86.

Who does even come up with a Path like:
"c:\program files (x86)\"

Not just having two Spaces in the Directory, but also putting a parathesis inside?!
...
C:\Programs for all languages would have done a perfect job!

I don't get it why where's a need for x64/x32 separation in Programs Files anyway....

[EricLaw]

If you don't provide virtualization by bitness, a variety of scenarios
would break.

And yes, the use of spaces in paths was an utterly dumb design
decision by the Windows 95 team who was so excited that you *could*
have spaces that they didn't consider whether you *should*. One of
Vista's wise reversals was doing away with that as much as possible.