0

I'm using a very old version of InstallShield Express 4 to package my VB6 application. Installing it on XP, it works great. But when I install it on a Windows 7 box, not using the "run as administrator", everything seems to be read-only. I can't edit an INI file because access is denied. The application just doesn't function properly. It's almost like it can't even access the folder. And it's installed in the default "program files" folder. I uninstall the application, reinstall using the "run as administrator" option, set compatibility of the short cut to "run as administrator", and everything works fine.

My question is this something inherited in VB6 where the application has to run as administrator or is it an InstallShield issue? And if it is an InstallShield Express issue, would the latest version of InstallSheild Express 2012 fix this? I would prefer the user not have to worry about installing or running the application as an administrator.

DrZ
  • 181
  • 5
  • 22

2 Answers2

3

Nothing is specifically wrong with your VB6 application. I would say it's the older version of InstallSheild which might be the problem in this case.

The feature is called User Access Control (UAC) that has been introduced in Windows Vista and the following Microsoft operating systems to prevent arbitrarily write access into %ProgramFiles% by applications. You can still perform it manually (by copying and pasting files into %ProgramFiles%) but UAC will prompt for your permission.

To make sure your application behaves expectedly, save application settings in %APPDATA% or in registry, NOT in %ProgramFiles% directory. During installation or uninstallation of your program which requires write access into %ProgramFiles%, you'll have to run it as administrator (unless of course you have UAC disabled which is a massive security risk and strongly recommended against).

gsbabil
  • 7,505
  • 3
  • 26
  • 28
  • Thank you gsbabil. I know my version of InstallShield doesn't know anything about the appdata folder. If you are familiar with InstallShield Express 12, is it smart enough to choose the appdata folder for Vista/Win 7 and program files for say XP? – DrZ Feb 29 '12 at 02:22
  • @Drz: I am not very familiar with InstallShield. But, if it is not a special requirement, why don't you try NSIS [1]. NSIS is Windows 7 and Vista compatible and very configurable. [1] http://nsis.sourceforge.net/Main_Page – gsbabil Feb 29 '12 at 06:19
  • @DrZ: Forgot to add - NSIS is free and quite popular in many big projects. – gsbabil Feb 29 '12 at 06:27
  • I'm going to try it gsbabil. Thank you again so much! – DrZ Feb 29 '12 at 11:18
  • 1
    Do you have Visual Studio 2010? If so, there's a free version of InstallShield ( Limited Edition ) that's available to you. – Christopher Painter Feb 29 '12 at 11:58
  • -1. There is something specifically wrong with the VB6 app: it is attempting to write to a directory under program files, which is read-only. You cannot solve this by changing to a different install program. You can solve this either by (i) making the install directory writeable (ii) changing the VB6 app to store its settings elsewhere (iii) always running the VB6 app as administrator. Changing the installation program is a waste of time. See my answer for more details – MarkJ Feb 29 '12 at 12:08
  • @MarkJ: Did you read my whole reply? If yes, tell me where I said that the problem can be solved only by switching to NSIS, as obviously I can not find it anywhere in my reply. I was merely suggesting NSIS as an alternative to InstallShield because of its reputation. Also, it is quite normal for older Windows apps to keep settings in INI files inside installation directory. – gsbabil Feb 29 '12 at 12:31
  • There is nothing wrong with the app, it's the new security design introduced in Windows Vista/7 that is causing OP the trouble. The app just needs to adapt to the new security design. This can be achieved by creating the INI inside a writable directory by the installer (NSIS should be able to do it) and change app such that it recognizes the new INI path. – gsbabil Feb 29 '12 at 12:31
  • @gsbabil I'm worried the OP will think that simply changing the installer will fix the problem. Part of the original question is "is this something... in VB6... or is it an InstallShield issue? ... would the latest version of InstallShield fix this?". I think your answer really needs to emphasise that the VB6 code needs to change. Currently you say "nothing is specifically wrong with the VB6" and you haven't explicitly told the OP to change the application. I know it's implied in your answer, but I think it needs to be more explicit. – MarkJ Feb 29 '12 at 14:40
  • @gsbabil BTW I wrote -1 in the original comment but I did not actually downvote. – MarkJ Feb 29 '12 at 14:47
2

Yes, there is something specifically wrong with your VB6 app. It is storing its data in the wrong place. Your application cannot access the program files folder, unless it is running as administrator. This is due to User Account Control, as explained in gsabil's answer.

Here are some solutions (the best one last)

  • Always run the VB6 app as administrator.
  • Turn User Account Control off. This opens some security holes and is not recommended
  • Make your install program change the permissions on your installation directory, granting write access for all users. This is rather a hack, but it could be a fast way to get your program working
  • Change your application (not your install program) so that it stores its data in %AppData% rather than in the installation directory. This is preferable. Here is some detailed advice on how to do this in VB6
Community
  • 1
  • 1
MarkJ
  • 30,070
  • 5
  • 68
  • 111
  • -1 for suggesting to turn off UAC which is security wise a big risk on Windows. UAC is not idiot-proof. But, it raises a fair bit of alarm when applications attempt to perform privileged operations. – gsbabil Feb 29 '12 at 12:38
  • @gsbabil. True enough, I will edit my answer to warn against disabling UAC – MarkJ Feb 29 '12 at 14:41