%programfiles% on x64 machines?
Simon
Hi,
On a 32bit windows machine %programfiles% evaluate to only one folder,
(in most cases something like 'C:\Program Files').
But on 64 bit OS most setup apps create 2 separate folders clearly
depending on the application, 'C:\Program Files' and 'C:\Program Files
(x86)'
But as far as I know there is still only one '%programfiles%' global
variable.
How can I query either folders?
Is %programfiles% effectively worthless now as I still have no clue what
folder it represents?
Or am I missing something else?
Thanks
Simon
Joseph M. Newcomer
to? I vaguely suspect that it might depend on the type of app that is asking for it. No
evidence, and I don't have time this week to fiddle with testing. My 64-bit machine is
undergoing some reconstructive surgery, and will not be online again for another month
(some delays in delivery of the upgraded parts...)
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
David Lowndes
Simon,
What do you need to do?
I notice that programmatically (via SHGetSpecialFolderPath) there are
CSIDL_PROGRAM_FILES, & CSIDL_PROGRAM_FILESX86 values.
Dave
Simon
>> How can I query either folders?
>> Is %programfiles% effectively worthless now as I still have no clue what
>> folder it represents?
>>
>> Or am I missing something else?
>
> Simon,
>
> What do you need to do?
>
> I notice that programmatically (via SHGetSpecialFolderPath) there are
> CSIDL_PROGRAM_FILES, & CSIDL_PROGRAM_FILESX86 values.
>
> Dave
Truth be told, I am not really trying to do anything for now.
I am just trying to learn the new rules of the game :)
For example, if I query the registry for a path, (something that my
application does from time to time), the path returned is sometime,
"%programfiles%\example\mainapp.exe"
In the past I could use PathUnExpandEnvStrings( ... ) to get the actual
location of the file.
But now I am not 100% sure that I will get the correct path at all.
How will the app know if it is "%programfiles%" or "%programfiles%
(x86)", or will PathUnExpandEnvStrings( ... ) know the difference and
expand the correct path?
Simon
David Webber
"Simon" <b...@example.com> wrote in message
news:uyJPtoi%23JHA...@TK2MSFTNGP03.phx.gbl...
> Truth be told, I am not really trying to do anything for now.
> I am just trying to learn the new rules of the game :)
>
> For example, if I query the registry for a path, (something that my
> application does from time to time), the path returned is sometime,
> "%programfiles%\example\mainapp.exe"
>
> In the past I could use PathUnExpandEnvStrings( ... ) to get the actual
> location of the file.
>
> But now I am not 100% sure that I will get the correct path at all.
Well the registry contains locations of files, and they're either right or
wrong. If they (or any environmant variables they contain) are wrong, the
the user is going to have problems with his computer long before he comes to
run your application.
> How will the app know if it is "%programfiles%" or "%programfiles% (x86)",
> or will PathUnExpandEnvStrings( ... ) know the difference and expand the
> correct path?
If they're defined environment variables, why shouldn't they both be
resolved correctly?
[I haven't looked at environment strings on a 64bit machine - but shouldn't
it be "%programfiles%" or "%programfiles(x86)%" or something lika that?]
If I were putting paths in the registry I wouldn't enclude environment
variables, but use the results found using the CSIDL constants which David
explained. (In fact I do <g>.)
Environment variables are useful - you can type "%programfiles% into the
top of windows explorer and go straight there :-) (In words attributed to
Michael caine: not a lot of people know that.) But as far as programming
goes, they feel rather "old hat" or "DOSSY" to me: the CSIDL constants are
the modern way to go. The only advantage I can see of having
"%programfiles% in a path in a registry entry, would be if you wanted to
change the location of the program files folder, and not update everything
in the registry. This is essentially *unthinkble*, as far as I am
concerned: it would surely break *everything*. (I am reminded of the days
when we moved from MS-DOS to 16-bit Windows, and found that if we moved
files around, things didn't work any more. There was a *lot* of whingeing
about that, but if you want a shell with all the properties which windows
gives you, then it (now) seems a small price to pay.)
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Simon
>>
>> But now I am not 100% sure that I will get the correct path at all.
>
> Well the registry contains locations of files, and they're either right
> or wrong. If they (or any environmant variables they contain) are
> wrong, the the user is going to have problems with his computer long
> before he comes to run your application.
True, but the problem is that I am not 100% how it works.
>
>> How will the app know if it is "%programfiles%" or "%programfiles%
>> (x86)", or will PathUnExpandEnvStrings( ... ) know the difference and
>> expand the correct path?
>
> If they're defined environment variables, why shouldn't they both be
> resolved correctly?
> [I haven't looked at environment strings on a 64bit machine - but
> shouldn't it be "%programfiles%" or "%programfiles(x86)%" or something
> lika that?]
>
> If I were putting paths in the registry I wouldn't enclude environment
> variables, but use the results found using the CSIDL constants which
> David explained. (In fact I do <g>.)
>
As far as I know, this is what environment variable are used for.
But in any case, as I am not the owner of the other apps I cannot assume
they will/will not use variables.
I have found the name of the variable, (%PROGRAMFILES(X86)%), (using the
dos cmd 'Set' gives all the variables and their values).
So based on that now know that %PROGRAMFILES% and %PROGRAMFILES(X86)%
are two distinct paths.
I was worried for a minute that MS took it upon itself to move x86 app
into a separate folder while keeping the name %PROGRAMFILES% for both of
them.
So in my case, using PathUnExpandEnvStrings( ... ) will still work.
Simon
David Webber
"Simon" <b...@example.com> wrote in message
news:%23buet5j%23JHA...@TK2MSFTNGP05.phx.gbl...
> True, but the problem is that I am not 100% how it works.
> As far as I know, this is what environment variable are used for.
Not really. Have look in your registry under
HKLM\Software\Microsoft\Windows\Current version\App Paths\
You'll find the full path to all applications there. Mine practically all
start C:\Program Files\...; None start %programfiles%
These entries are used to resolve the location of the program. (For
example if you type
start myprog.exe
on a command line.) Environment variables can be useful in .bat files,
but you really shouldn't need them for proper programs (at least i can't
think of any reason off hand). The registry is far more powerful and
stores a lot more information.
> But in any case, as I am not the owner of the other apps I cannot assume
> they will/will not use variables
?
A well behaved application should be registered in the "App Data" section of
the registry. Have a look in yours and see what's there.
> I have found the name of the variable, (%PROGRAMFILES(X86)%), (using the
> dos cmd 'Set' gives all the variables and their values).
>
> So based on that now know that %PROGRAMFILES% and %PROGRAMFILES(X86)% are
> two distinct paths.
That's what I'd have expected.
> I was worried for a minute that MS took it upon itself to move x86 app
> into a separate folder while keeping the name %PROGRAMFILES% for both of
> them.
How could it? The environment variable simply maps onto a path string - it
can only have one value.
> So in my case, using PathUnExpandEnvStrings( ... ) will still work.
I should expect so. And if some of your registry entries really do
contain %programfiles% etc. it may be useful.
Joseph M. Newcomer
Environment variables are crude hack that predate Unix.
Unix did not invent them, but took them from predecessor systems.
But they are largely a crude hack.
Also, you probably meant ExpandEnvironmentStrings, not PathUnexpandEnvStrings, since
PathUnxpandEnvStrings is probably how the name was created in the first place.
joe
Simon
>> True, but the problem is that I am not 100% how it works.
>
>> As far as I know, this is what environment variable are used for.
>
> Not really. Have look in your registry under
> HKLM\Software\Microsoft\Windows\Current version\App Paths\
Not all apps use that registry, they don't have to, probably only if you
want the short-cut as you describe bellow.
> You'll find the full path to all applications there. Mine practically
> all start C:\Program Files\...; None start %programfiles%
>
> These entries are used to resolve the location of the program. (For
> example if you type
>
> start myprog.exe
Not true either, as an example that we might both share, I suspect that
none of your games are listed there.
Virtual PC.exe or Remote desktop are also probably not listed for example.
>
>> But in any case, as I am not the owner of the other apps I cannot
>> assume they will/will not use variables
>
> A well behaved application should be registered in the "App Data"
> section of the registry. Have a look in yours and see what's there.
Not true, only if you want to add a shortcut.
You might see the entry setup.exe does not have a path.
>> I have found the name of the variable, (%PROGRAMFILES(X86)%), (using
>> the dos cmd 'Set' gives all the variables and their values).
>>
>> So based on that now know that %PROGRAMFILES% and %PROGRAMFILES(X86)%
>> are two distinct paths.
>
> That's what I'd have expected.
Same here, but I have leaned not to make any assumptions about the way
the OS behaves.
>> I was worried for a minute that MS took it upon itself to move x86 app
>> into a separate folder while keeping the name %PROGRAMFILES% for both
>> of them.
>
> How could it? The environment variable simply maps onto a path string
> - it can only have one value.
>
>> So in my case, using PathUnExpandEnvStrings( ... ) will still work.
>
> I should expect so. And if some of your registry entries really do
> contain %programfiles% etc. it may be useful.
A very quick search of %programfiles% returns a lot of entries, (and a
lot of them as MS files), so it looks like variables are very much used.
Simon
David Webber
"Simon" <b...@example.com> wrote in message
news:O%23OvNjl%23JHA...@TK2MSFTNGP05.phx.gbl...
>>> True, but the problem is that I am not 100% how it works.
>>
>>> As far as I know, this is what environment variable are used for.
>>
>> Not really. Have look in your registry under
>> HKLM\Software\Microsoft\Windows\Current version\App Paths\
>
> Not all apps use that registry, they don't have to, probably only if you
> want the short-cut as you describe bellow.
I know that it's nice if programs run from a pen drive and so on, but I
would still maintain that anything installed in C:\Program Files\ should be
registered in the App Paths area. There are surely other reasons than the
start command line. I mean I can launch Internet Explorer with "start
iexplore.exe" but I don't for a moment imagine that anyone actually does!
Interestingly write.exe has an entry which launches wordpad :-) [I still
have a copy of the real write.exe but seldom use it these days]
>> You'll find the full path to all applications there...
> Not true either, as an example that we might both share, I suspect that
> none of your games are listed there.
I wouldn't know: I don't even know the names of the executables for
minesweeper and spider solitaire. (However searching, on a hunch, for
minesweeper.exe finds quite a few entries, so it isn't that the registry
doesn't know anything about it.) And I have never felt the need of any
other games.
> Virtual PC.exe or Remote desktop are also probably not listed for example.
I have no idea whether they would be or not. But other tools are - like
devenv.exe
>>> But in any case, as I am not the owner of the other apps I cannot assume
>>> they will/will not use variables
>>
>> A well behaved application should be registered in the "App Data" section
>> of the registry. Have a look in yours and see what's there.
>
> Not true, only if you want to add a shortcut.
> You might see the entry setup.exe does not have a path.
I wouldn't expect installers to be in the registry - you'd need a program to
install the installation program to put the information there! And then
you'd need an installer for that one. And then.... So yes I was using
the phrase "all programs" with a certain degree of flexibility.
>... A very quick search of %programfiles% returns a lot of entries, (and a
>lot of them as MS files), so it looks like variables are very much used.
That's interesting - now I look carefully, I have a few, but not many in
AppData.
David Lowndes
>Truth be told, I am not really trying to do anything for now.
>I am just trying to learn the new rules of the game :)
I think the rules can be determined from the KNOWNFOLDERID
documentation - there's a table at the end that shows which
directories the ID's refer to in different circumstances.
Dave
Simon
>>
>> Not all apps use that registry, they don't have to, probably only if
>> you want the short-cut as you describe bellow.
>
> I know that it's nice if programs run from a pen drive and so on, but I
> would still maintain that anything installed in C:\Program Files\ should
> be registered in the App Paths area.
Maybe it is nice to have such a shortcut, but it is not a requirement.
You cannot say with certainty that an app installed is listed in the App
Paths area, (or even that it should be).
> There are surely other reasons
> than the start command line. I mean I can launch Internet Explorer with
> "start iexplore.exe" but I don't for a moment imagine that anyone
> actually does!
I do, I use my mouse as little as possible so I do type 'iexplore'.
But anyway, I think one of the other reasons is that I can shell execute
iexplore from anywhere without having to resolve the path.
I don't know what App Paths is used for, probably only as a global shortcut.
> Interestingly write.exe has an entry which launches wordpad :-) [I
> still have a copy of the real write.exe but seldom use it these days]
And you can change it to anything else, mine has been changed to
notepad++, (although notepad++ has its own entry).
>
> I wouldn't know: I don't even know the names of the executables for
> minesweeper and spider solitaire. (However searching, on a hunch, for
> minesweeper.exe finds quite a few entries, so it isn't that the registry
> doesn't know anything about it.) And I have never felt the need of any
> other games.
minesweeper is winmine.exe
solitaire is sol.exe
the minesweeper you are finding is because this is what most people will
type, ... on a hunch.
>
>> Virtual PC.exe or Remote desktop are also probably not listed for
>> example.
>
> I have no idea whether they would be or not. But other tools are -
> like devenv.exe
They are installed, so by your own reasoning they should be there.
MS added devenv.exe because some of use type 'devenv' to launch the IDE.
>>> A well behaved application should be registered in the "App Data"
>>> section of the registry. Have a look in yours and see what's there.
>> Not true, only if you want to add a shortcut.
>> You might see the entry setup.exe does not have a path.
> I wouldn't expect installers to be in the registry - you'd need a
> program to install the installation program to put the information
> there! And then you'd need an installer for that one. And
> then.... So yes I was using the phrase "all programs" with a certain
> degree of flexibility.
no, setup.exe actually resolves to something.
try it and you will see.
The reason you gave has nothing to do with it been there, there is no
requirement for an install program adding an entry in App Paths
>> ... A very quick search of %programfiles% returns a lot of entries,
>> (and a lot of them as MS files), so it looks like variables are very
>> much used.
>
> That's interesting - now I look carefully, I have a few, but not many in
> AppData.
>
> Dave
I think you are mistaken about the use of AppData.
Simon
Simon
Thanks,
http://msdn.microsoft.com/en-us/library/dd378457(VS.85).aspx seems to
list %ProgramFiles(x86)% as well for x64 OS, so by the looks of things
everything should work without changing anything.
Thanks
Simon
David Webber
"Simon" <b...@example.com> wrote in message
news:%23L2brvt%23JHA...@TK2MSFTNGP02.phx.gbl...
>> There are surely other reasons than the start command line. I mean I can
>> launch Internet Explorer with "start iexplore.exe" but I don't for a
>> moment imagine that anyone actually does!
>
> I do, I use my mouse as little as possible so I do type 'iexplore'.
That doesn't work for me - I don't have much on my default paths. But
"start iexplore.exe" works fine. (that doesn't work for sol.exe or
winmine.exe - so yes they are omitted from the App ptahts in the registry.)
> But anyway, I think one of the other reasons is that I can shell execute
> iexplore from anywhere without having to resolve the path.
> I don't know what App Paths is used for, probably only as a global
> shortcut.
It allows you to find the full path to a program from the exe file name.
The command line start command uses it, but other things can too.
>> Interestingly write.exe has an entry which launches wordpad :-) [I
>> still have a copy of the real write.exe but seldom use it these days]
>
> And you can change it to anything else, mine has been changed to
> notepad++, (although notepad++ has its own entry).
I'm a fan of notepad++ too - but I usually don't want to see all the rtf
mark-up.
>>... devenv.exe
>
> They are installed, so by your own reasoning they should be there.
> MS added devenv.exe because some of use type 'devenv' to launch the IDE.
I use it from batch files to compile a whole set of language translation
resource-only DLLs.
>>>> A well behaved application should be registered in the "App Data"
>>>> section of the registry. Have a look in yours and see what's there.
>
>>> Not true, only if you want to add a shortcut.
>>> You might see the entry setup.exe does not have a path.
>
>> I wouldn't expect installers to be in the registry - you'd need a program
>> to install the installation program to put the information there! And
>> then you'd need an installer for that one. And then.... So yes I was
>> using the phrase "all programs" with a certain degree of flexibility.
>
> no, setup.exe actually resolves to something.
> try it and you will see.
Ok "start setup.exe" opens the setup folder within the windows folder.
How bloody confusing: whoever called that setup.exe should be shot at dawn!
> I think you are mistaken about the use of AppData.
No - I know what it's for. I grant that I may have somewhat overestimated
the number of programs which have an entry there though.