Hi
A program I made about a year ago on my Win XP machine for a client on XP is now being used by the client on a Win 7 laptop. The client is reporting that the program will not run when installed through the Installer I created (Inno), but the program will work if he just copies it from his XP machine into a folder that is not the ProgramFiles folder.
Does anyone know why this may be happening?
thanks
What does that mean? Does it not install? Is there an error when they try to run it? How do they run it? Shortcut? Something else?
Thanks for the fast reply Paul.
The installer seems to do everything ok as far as I can tell. Files end up in Program Files (x86) and desktop and Start Menu shortcuts are created. When the shortcut is double-clicked or the Start Menu shortcut is clicked or the program file in Program Files (x86) is clicked the program will not start but generates a Nil Object Exception.
The client has copied the program exe file and Libs folder into another folder, not in Program Files (x86) and it works fine when he double clicks the program file. He is suggesting that the problem is because there is no digital signature in the program file or installer. Is he correct?
My guess : it’s due to registry or folder virtualization: http://support.microsoft.com/kb/927387
The solution is to make sure your app’s manifest is set properly, and that the app doesn’t do illegal stuff : in XP an app could basically do anything, whereas sensible security limitations in Vista and 7 prevent your app from running amok.
Under Windows 7, a program is ‘not allowed’ to create or modify a file in a folder inside Program Files.
Your app should be creating temp files and documents in the My Documents folder or the ApplicationData folder.
An attempt to create a file ‘where the EXE lives’ will fail if installed in Program Files, but will work fine if you take the whole folder and put it into (for example) My Documents.
For legacy apps that you don’t have the source code for, a quick (and admittedly dirty) hack is to rework the installer so that the whole shebang goes into ‘My Documents’.
The end user doesn’t need to know where the app is, as long as the icon launches it.
Surely that’s only if the installer doesn’t have administrator privileges.
Try to put “PrivilegesRequired=poweruser” in the [SETUP] Section and reinstall. Does it fix the issue?
The installer installs files into that folder no problem.
It is the deployed app that fails to create files when it is run. Thats why it works when placed into a folder where it DOES have write permission. Ive seen many Windows 95/XP era applications suffer from this problem.
The installer has admin privileges, but your application does not unless you right-click the EXE and select “Run as Administrator”
Add an entry in the [Registry] Section:
f.e. Root: "HKLM"; Subkey: "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\"; ValueType: String; ValueName: "{app}\\YOURAPPexe"; ValueData: "RUNASADMIN"; Flags: uninsdeletekeyifempty uninsdeletevalue; MinVersion: 0,6.1This will allow your App to run with Admin privileges right after the installation.
Sascha… good suggestion! I didn’t have that in the installer script. I’ll make the amend and see what the client makes of it.
Thanks
“{app}\YOURAPPexe” should be {app}\YOURAPP.exe 
Also - it’s very important to test under both an Admin and Non-Admin user. The vast majority of of XP users historically are running as Admin users, but a lot of Windows Vista/7/8 users are running as non-admin users. Test under all combinations to be sure.
Instead of installing your app in the Programs Files folder, try installing it in the C:\Users\Public folder. We had to do that because we had a SQLite database that was read and written to. OS Vista and above does not allow you to write data to the Program Files folder, just as Apple’s Lion and above does not allow you to write data to the Applications folder.
The solution for us in Windows was to move the targeted install folder from \Program Files to Users\Public. After that everything worked fine.
A Programm on Windows should be installed in the Programm files folder.
Just move all filesystem input/output tasks outside the Programs Folder, use “My Documents” for this.
Thank you al of you who gave replies. I have tracked down one problem to the app open event where I was trying to write a file out to the same folder as the program file. I have changed it to write to the Application Support area and the program will now run.
Next problem - the program will not accept drag and drop text files onto a list box on the opening window!! It did in XP!
Any suggestions would be welcome.
I am having a similar problem. My app will start but it won’t write pressure readings to a Label. It works fine if run from another folder. It reads pressure thru the serial port. I wasn’t sure where the problem was until reading this thread. The app works fine in the IDE and and running the compiled version, just not when it’s installed in the Program Folder. Any ideas why reading the serial port won’t work?
If the app is running with Administrative privileges, you can’t DnD from the user’s desktop / Explorer window. Another of the “protect the users from themselves at all costs” moves by MS in Vista and newer.
You can also see this in the IDE. Start the IDE with “Run as Administrator” and try to drag an image into the Project panel.
I haven’t found any mechanism around this.