I need to create a registry key pointing to a file located in the 32 Bit "Program Files" folder that works under both versions (i.e. x86 and x64) of Windows 7 (and higher), even if the accessing process is a 64Bit process in the x64 environment. This folder is:
C:\Program Files in 32Bit Windows
C:\Program Files (x86) in 64 Bit Windows
My problem currently is, that the %programfiles(x86)% variable is not set on 32 Bit windows. So I do not really know which unique variable I can use on both Windows systems to get to the 32 Bit Program Files folder. Any solution to this weird situation?
I am trying to use C:\Prpgram Files (x86) on X64 machine and C:\Program Files on X86 machine in my build to refer to a VBA path like blow
I use the following path in my Project ->Properties -> C++ -> Additional Include Directrories
C:\$(MSBuildExtensionsPath32)\VBA6SDK\include
But I get compilation errors on a X86 machine since It cant find some header files located at
C:\Program Files\VBA6SDK\include
if I replace $(MSBuildExtensionsPath32) with "program files" no issues.
This is a MFC project that I am building using VS2010.
What am I missing ?
The $(MSBuildExtensionsPath32) property normally contains "C:\Program Files (x86)\MSBuild". The directory where MSBuild extensions are stored.
This of course has nothing to do with the VBA6SDK you are trying to use so the property is not very useful. You can use $(ProgramFiles) to use the system environment variable, it will be C:\Program Files (x86) on a 64-bit English operating system for the 32-bit toolchains. Don't prefix with C:\
If an application is built on a 32-bit machine, when run on a 64-bit machine, how does it know the .dll is in C:\Program Files (x86) instead of C:\Program Files or it doesn't?
ERROR SUMMARY
[SCRIPT]: File not found: C:\Program Files\Common Files...\abc.dll.
However, in my 64-bit machine, abc.dll is in C:\Program Files (x86)\Common Files...\abc.dll
If it doesn't, where do I adjust the path because apparently it's not in the application's code.
First of all, you can cross-compile in either direction so being built on a 32-bit machine doesn't necessarily mean anything. It is really an issue of running 32-bit code on a 64-bit machine. In this case, there is a 32-bit emulation layer on 64-bit installations called Wow64. Part of this is file system redirection, which redirects file system requests from 32-bit programs. In this case, trying to access "C:\Program Files" from 32-bit code will transparently redirect to "C:\Program Files (x86)".
it doesn't?
No part of the default search path checks anywhere in Program Files or Program Files (x86) unless it is because the directory of the application is under one of those folders.
If you are getting that error from a 32bit application then something is set up unusually (like overriding the default install location under Program Files (x86)).
How do I determine the full path of the folder that contains 32-bit programs using VBA? It's called "Program Files" on 32-bit Windows systems, but on 64-bit systems it's called "Program Files (x86)".
Environ will do the trick:
debug.print Environ("ProgramFiles")
debug.print Environ("PROGRAMFILES(X86)")
'If you want to check if current PC is x64
debug.print Environ("PROCESSOR_IDENTIFIER")
List of environment variables can be found here.
UPDATE: Based on the conversation I've had with Christian and based on my comments, I looked into this a little more.
I have two machines I tested on:
Machine 1: Win 7 Ultimate, 64 Bit, Office 2010 64 Bit
Machine 2: Win 7 Ultimate, 32 Bit, Office 2007 32 Bit
I ran the following statements in the immediate window:
? Environ("ProgramFiles")
? Environ("PROGRAMFILES(X86)")
? Environ("ProgramW6432")
Results
Machine 1:
C:\Program Files
C:\Program Files (x86)
C:\Program Files
Machine 2:
C:\Program Files
//Blank//
//Blank//
So, based on these limited findings, you may want to see the if ProgramW6432 has a value. If not, assume 32 bit and use ProgramFiles.
IF Environ("ProgramW6432") <> "" THEN
'I'm 64 bit so check both ProgramW6432 and PROGRAMFILES(X86)
ELSE
'I'm 32 bit so check ProgramFiles
END IF
Conversely, you could use PROCESSOR_IDENTIFIER to determine x64 vs. x86 and do the same thing.
I wouldn't say either way is foolproof but should get you on the right track.
One-stop shop
I thought I'd summarize the conclusions that can be drawn from the information scattered across all answers here, plus a bit of integration on my part. Credits to all previous answer posters!
The output of Environ for any given "program file"-related environment variable will vary depending on Windows (32 or 64 bit) as well as Office (32 or 64 bit) as follows:
Windows Office ProgramFiles PROGRAMFILES(X86) ProgramW6432
------- ------ ---------------------- --------------------- ----------------
32-bit 32-bit C:\Program Files [empty string] [empty string]
64-bit 32-bit C:\Program Files (x86) C:\Program Files (x86) C:\Program Files
64-bit 64-bit C:\Program Files C:\Program Files (x86) C:\Program Files
Note that for the Windows 64 bit + Office 32 bit setup, the output of Environ("ProgramFiles") does not match with the actual value of the ProgramFiles environment variable in Windows! At the command prompt, echo %ProgramFiles% returns C:\Program Files, not C:\Program Files (x86).
If you need the path to the 32 bit program files folder (C:\Program Files for 32-bit Windows, and C:\Program Files (x86) for 64-bit Windows) then you can use this function:
Function Get32BitProgramFilesPath() As String
If Environ("ProgramW6432") = "" Then
'32 bit Windows
Get32BitProgramFilesPath = Environ("ProgramFiles")
Else
'64 bit Windows
Get32BitProgramFilesPath = Environ("ProgramFiles(x86)")
End If
End Function
ray023's answer is basically correct, but one addition:
At least on my machine (Win 7 Home Premium 64 bit, Access 2000 installed), both
Environ("ProgramFiles") and
Environ("PROGRAMFILES(X86)")
...return the same folder, C:\Program Files (x86).
To get the "non-x86-folder" (C:\Program Files) on my 64 bit Windows, I need to use Environ("ProgramW6432").
Here's another link about the Environ function, including code how to list all environment variables (that's how I found ProgramW6432).
EDIT:
As I already said in a comment, I just tested it on my other machine as the results seem to depend not only on the operating system, but on the installed MS Office version as well:
This machine runs on Win XP SP3 32-bit, and Access 2000 is installed:
Environ("ProgramFiles") returns C:\Programme.
(that's "Program Files" in German - I'm in Germany and my Windows is in German)
Environ("PROGRAMFILES(X86)") and Environ("ProgramW6432") return an empty string.
--> So the safest way to determine the "x86 folder" (no matter if on Win XP or Win 7) seems to be Environ("ProgramFiles").
Here is an article showing you how to read this information from the registry:
http://accesstips.wordpress.com/2010/01/08/get-a-computers-program-files-folder-path-with-access-vba-and-wmi/
In the comments of that article is also a hint how to retrieve the information from the environment variable "ProgramFiles". But beware, if you have different partitions, there may be more than one "Program Files" folder, for example "C:\Program Files" and "D:\Program Files".
Environ("ProgramFiles") is enough statement for both 32 bit and 64 bit system ... in 64 bit you will get
Result C:\Program Files (x86)
Does anyone know if windows 7 will somehow defer back to the "ProgramFiles(X86)" environmental variable when the "ProgramFiles" variable is used?
We have a situation where a developer is using visual studio and the proj file references assemblies using "$(ProgramFiles)". The machine is 64-bit and the "ProgramFiles" variable points to "C:\Program Files", however the assemblies are in "C:\Program Files (X86)" yet the project builds. It does not build if the literal "C:\Program Files" path is used. The compiler says it cannot find the assemblies
Yes, Windows automatically maps folder and file access to c:\program files for 32-bit programs to c:\program files (x86). Visual Studio as well as MSBuild are 32-bit programs. Same is true for c:\windows\system32 vs c:\windows\syswow64.