This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Value of PROGRAMFILES and PROGRAMFILES64 defines
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Mar 02, 2015
09:12 AM
Value of PROGRAMFILES and PROGRAMFILES64 defines
I did a little testing with my Installshield 2014 Premier on a Windows Server 2012 R2 machine, and found a strange problem on a (64 bits) Windows Server 2012 R2 machine (Installscript project).
I created a new Installscript project and added the following piece of code to the OnFirstUIBefore event:
if ( SYSINFO.bIsWow64 = 0 ) then
TARGETDIR = PROGRAMFILES ^ "Priva";
MessageBox( "bIsWow64 = 0 (32 bits), TARGETDIR: " + TARGETDIR + "\n" +
"PROGRAMFILES: " + PROGRAMFILES + "\n" +
"PROGRAMFILES64: " + PROGRAMFILES64 + "\n" +
"WINSYSDIR: " + WINSYSDIR + "\n" +
"WINSYSDIR64: " + WINSYSDIR64
, INFORMATION );
else
TARGETDIR = PROGRAMFILES64 ^ "Priva";
MessageBox( "bIsWow64 != 0 (64 bits), TARGETDIR: " + TARGETDIR + "\n" +
"PROGRAMFILES: " + PROGRAMFILES + "\n" +
"PROGRAMFILES64: " + PROGRAMFILES64 + "\n" +
"WINSYSDIR: " + WINSYSDIR + "\n" +
"WINSYSDIR64: " + WINSYSDIR64
, INFORMATION );
endif;
The contents of the Installshield messagebox can be seen in the image below, the value of PROGRAMFILES and PROGRAMFILES64 are exactly the same. Also the values for WINSYSDIR and WINSYSDIR64 are exactly the same.
The Online help of Installshield tells me the value of PROGRAMFILES64 is: During setup initialization in InstallScript installations, the value of the PROGRAMFILES64 variable is obtained by calling the Windows API function SHGetSpecialFolderPath with the CSIDL_PROGRAM_FILES parameter from a 64-bit executable file (from your Help system).
So I basically implemented a 64 bit binary to retrieve those values as well. In this case the call to retrieve the CSIDL_PROGRAM_FILES correctly returns ‘C:\Program Files’. See also the results in the image above.
I really don’t know why the PROGRAMFILES64 returns ‘C:\Program Files (x86)’ from my Installscript project.
It only happens on a single machine, other 64 bit machines correctly return the PROGRAMFILES64 as being ‘C:\Program Files’. I also did the same test with an Installscript project in Installshield 2013, same problem.
I searched the Internet, forums for any information related to this issue. Up to now I haven’t been able to find any information helping me to solve this.
I created a new Installscript project and added the following piece of code to the OnFirstUIBefore event:
if ( SYSINFO.bIsWow64 = 0 ) then
TARGETDIR = PROGRAMFILES ^ "Priva";
MessageBox( "bIsWow64 = 0 (32 bits), TARGETDIR: " + TARGETDIR + "\n" +
"PROGRAMFILES: " + PROGRAMFILES + "\n" +
"PROGRAMFILES64: " + PROGRAMFILES64 + "\n" +
"WINSYSDIR: " + WINSYSDIR + "\n" +
"WINSYSDIR64: " + WINSYSDIR64
, INFORMATION );
else
TARGETDIR = PROGRAMFILES64 ^ "Priva";
MessageBox( "bIsWow64 != 0 (64 bits), TARGETDIR: " + TARGETDIR + "\n" +
"PROGRAMFILES: " + PROGRAMFILES + "\n" +
"PROGRAMFILES64: " + PROGRAMFILES64 + "\n" +
"WINSYSDIR: " + WINSYSDIR + "\n" +
"WINSYSDIR64: " + WINSYSDIR64
, INFORMATION );
endif;
The contents of the Installshield messagebox can be seen in the image below, the value of PROGRAMFILES and PROGRAMFILES64 are exactly the same. Also the values for WINSYSDIR and WINSYSDIR64 are exactly the same.
The Online help of Installshield tells me the value of PROGRAMFILES64 is: During setup initialization in InstallScript installations, the value of the PROGRAMFILES64 variable is obtained by calling the Windows API function SHGetSpecialFolderPath with the CSIDL_PROGRAM_FILES parameter from a 64-bit executable file (from your Help system).
So I basically implemented a 64 bit binary to retrieve those values as well. In this case the call to retrieve the CSIDL_PROGRAM_FILES correctly returns ‘C:\Program Files’. See also the results in the image above.
I really don’t know why the PROGRAMFILES64 returns ‘C:\Program Files (x86)’ from my Installscript project.
It only happens on a single machine, other 64 bit machines correctly return the PROGRAMFILES64 as being ‘C:\Program Files’. I also did the same test with an Installscript project in Installshield 2013, same problem.
I searched the Internet, forums for any information related to this issue. Up to now I haven’t been able to find any information helping me to solve this.
(7) Replies
‎Mar 02, 2015
01:45 PM
What happens if you use the following:
Disable(WOW64FSREDIRECTION);
See the topic 'Targeting 64-Bit Operating Systems with InstallScript Installations' in the help document.
I wonder if that is what you are seeing. When the messagebox appears, because you are a 32bit app, that Windows redirects to a 32-bit value. At least this is my understanding of how this works.
Disable(WOW64FSREDIRECTION);
See the topic 'Targeting 64-Bit Operating Systems with InstallScript Installations' in the help document.
"Although the WINSYSDIR64 variable is set to the 64-bit Windows folder, 64-bit Windows includes functionality to automatically redirect 32-bit applications (such as the InstallScript engine) to the 32-bit System32 folder (SysWOW64). "
I wonder if that is what you are seeing. When the messagebox appears, because you are a 32bit app, that Windows redirects to a 32-bit value. At least this is my understanding of how this works.
‎Mar 03, 2015
01:24 AM
DLee65 wrote:
What happens if you use the following:
Disable(WOW64FSREDIRECTION);
See the topic 'Targeting 64-Bit Operating Systems with InstallScript Installations' in the help document.
I wonder if that is what you are seeing. When the messagebox appears, because you are a 32bit app, that Windows redirects to a 32-bit value. At least this is my understanding of how this works.
The issue regarding the incorrect PROGRAMFILES64 is only happening on a single 64 bits Windows Server 2012 R2. I've installed on hunderds of 64 bits OS'es, where the PROGRAMFILES64 is correct. The installshield help also states they're using a 64 bit binary to retrieve the value of PROGRAMFILES64. This should work without any problem, even if the setup is a 32 bit binary.
The amazing part is the Windows API function SHGetSpecialFolderPath with the CSIDL_PROGRAM_FILES parameter returns the correct information, if I program those lines of code in C# 64 bit binary OR a Delphi Object Pascal 64 bit binary (like I did). So why does Installshield return the incorrect value on this specific machine?? I don't know.
I could of course easily switch to some environment variable, pointing to the correct location. It's just that I don't know why the PROGRAMFILES64 is incorrect on this specific 64 bit Windows Server 2012 R2 machine.
‎Mar 27, 2015
11:59 AM
I discovered this issue in IS 2014 back in July 2014. Flexera admitted it was a bug in August 2014.
Here's a link to the known issues and take a look at IOJ-1664081.
http://flexerasoftware.force.com/articles/en_US/INFO/InstallShield-2014-Known-Issues
In January 2015 I received an update to my incident to say the bug had been fixed in IS 2014 SP1. After I updated a IS 2013 project which handles both x86 and x64 native installs, I found yesterday that the issue has not been fixed in IS 2014 SP1. I have re-opened my incident and I am awaiting a response.
For now I have added a workaround to get the correct PROGRAMFILES64 as follows...
szProgramFiles64 = PROGRAMFILES;
StrReplace(szProgramFiles64, " (x86)", "", 0);
I urge you to open an incident if you can. I will update this thread if I hear any more. I'm finding IS 2014 extremely buggy and I'm considering back-revving. :mad:
HTH
Here's a link to the known issues and take a look at IOJ-1664081.
http://flexerasoftware.force.com/articles/en_US/INFO/InstallShield-2014-Known-Issues
In January 2015 I received an update to my incident to say the bug had been fixed in IS 2014 SP1. After I updated a IS 2013 project which handles both x86 and x64 native installs, I found yesterday that the issue has not been fixed in IS 2014 SP1. I have re-opened my incident and I am awaiting a response.
For now I have added a workaround to get the correct PROGRAMFILES64 as follows...
szProgramFiles64 = PROGRAMFILES;
StrReplace(szProgramFiles64, " (x86)", "", 0);
I urge you to open an incident if you can. I will update this thread if I hear any more. I'm finding IS 2014 extremely buggy and I'm considering back-revving. :mad:
HTH
‎Apr 14, 2015
04:43 AM
Good news is that Flexera have admitted there is an issue with IS 2014 SP1 where InstallScript projects using PROGRAMFILES64 will not resolve correctly (returns "C:\Program Files (x86)\") during an upgrade. New installs do not have this issue.
Hopefully we won't have to wait too long for a fix!
Hopefully we won't have to wait too long for a fix!
‎Jun 24, 2015
07:23 AM
MutleyUK wrote:
Good news is that Flexera have admitted there is an issue with IS 2014 SP1 where InstallScript projects using PROGRAMFILES64 will not resolve correctly (returns "C:\Program Files (x86)\") during an upgrade. New installs do not have this issue.
Hopefully we won't have to wait too long for a fix!
Thanks for the info, I'll use the workaround for now. I reported this to Flexera as well. While they already knew they had a bug in their software, they just wanted my to pay more money to solve the problem. That's lousy support!
‎Jun 25, 2015
10:43 AM
A hotfix was provided for the following issues on April 23:
ISDEV-37177 (IOJ-1726120) - Image on left-side of Skinned Dialog not visible on Progress Dialog in InstallScript
ISDEV-37240 (IOJ-1727555) - PROGRAMFILES64 resolves to 32 bit path during an Upgrade.
These fixes were issued for IS 2014 SP1.
ISDEV-37177 (IOJ-1726120) - Image on left-side of Skinned Dialog not visible on Progress Dialog in InstallScript
ISDEV-37240 (IOJ-1727555) - PROGRAMFILES64 resolves to 32 bit path during an Upgrade.
These fixes were issued for IS 2014 SP1.
‎Jun 25, 2015
01:14 PM
The hotfix KB article links are available from the InstallShield 2014 Known Issues KB article:
http://support.installshield.com/kb/view.asp?articleid=000017081
http://support.installshield.com/kb/view.asp?articleid=000017081