Archive: Different install locations according to Windows version


Different install locations according to Windows version
  Hello!

I have multiple applications which have problems with the way UAC redirects to VirtualStore when they are installed in Program Files. That is why I want for Windows Vista and 7 to have a different default install location. For example I want to install in Program Data when it comes to Vista and 7 and Program Files when on Windows XP.

Can it be done and how? Please explain as if I am a 2 year old :)... I use NSIS strictly to create an installer so I am at a very basic level!

Thank you very much!


!include winver.nsh

function .onInit
${If} ${AtLeastWinVista}
StrCpy $INSTDIR "D:\YourDir"
${Else}
StrCpy $INSTDIR "$PROGRAMFILES\YourApp"
${EndIf}
FunctionEnd
>
But this is NOT the solution. If your appplication writes to its own installation directory (and thus ends up in VirtualStore), then your application is BROKEN. Badly designed. Defective.

To comply with the way Microsoft Windows is designed, you need to use $APPDATA to save your application's configuration files, not $INSTDIR.

...and once you've changed the applications so that it doesn't write to the program directory, don't forget to add a manifest to the application, so that Vista and 7 disable the VirtualStore redirections..


I know this is a trend, but originaly my application wasn't designed that way and I don't want to go in too much trouble to change it... It seems stupid to me that instead of using one folder, which can easily be tracked spread a software over 10 folder across 10 partitions on 2 drivers. It's just plain stupid... the only reason it would make sense too keep settings in a different location is if you have multiple user accounts, in any other case it just complicates programmers life. But when it comes to Microsoft...


I agree with your sentiment, but keep in mind that there are good security reasons for why Microsoft changed these things. Whether you agree with those security reasons on their own is another discussion, but since half the world whined about Windows being too insecure and then complained about UAC when they made it more secure, they really can't win on that front.

That said.. you -can- still use a single folder; use the AppData or LocalAppData folders (with your own folder as a subfolder thereof, of course). There are some 'best practices' that say it's better if you didn't use those folders to store everything, but there's no reason you can't; Google's Chrome browser, for example, is practically completely in LocalAppData.
The main problem I have with this is that said location is not normally accessible by end-users; the folder is Hidden.. so you have to tell them to turn on 'Show hidden files & folders' first, etc.
On the other hand.. application+configuration migration policies already include copying the LocalAppData bits and pieces (though more appropriate still for config files and such is AppData\Roaming)


You are both wrong. Microsoft didn't change ANYTHING. Users haven't had writing access to $PROGRAMFILES since windows NT 4.0, as far as I remember. It's just that since Vista, new users aren't automatically put into the Administrators group. And this is NOT plain stupid. This is, in actuality, plain normal common sense.

adriantc, if your application didn't use Application Data before, then your application has been broken from the very first time you released it. Please comply to Windows software design specifications when you're creating Windows software.

Sorry for this rant. No personal comments implied, it's just that badly designed software is, well, bad.


You can't say "Microsoft didn't change anything" and then follow that up with "since Vista, new users aren't automatically put into the Administrators group"; that -is- a change.

I'll leave discussions over the pros and cons of that change to another forum, and in the mean time point out that you mostly certainly can still install to a single folder; as long as you do so within e.g. LocalAppData. Either way the application would have to be modified.


Originally posted by Animaether
You can't say "Microsoft didn't change anything" and then follow that up with "since Vista, new users aren't automatically put into the Administrators group"; that -is- a change.
In a domain setup, users are probably not admin on 2000/XP either (One would hope)

Even on 9x where everyone is admin, allowing users to change files in programfiles really breaks down when more than one user wants to use that program.

So that leaves you with two options:
a) Single user install: install app in $localappdata\programs\yourapp and keep the program data in the same place or in $appdata

b) All users install: install app in $programfiles and if you have any shared default data, store that also in $programfiles or $programfiles\Common Files and copy it out to $appdata the first time your app runs

I have analyzed both options already, but I'll have to stick with the first. Not only it forces me to change the application a little, but changes also have to be done to revert those when it comes to making my application portable... or update the portable version - since that requires keeping everything local.

Since I choose the first option is there any way to let users select the appdata folder, but if they want to change it get a message or something? Not to stop them, just to let them know it's better to let the default one!


I guess you could have a custom page or a 2nd directory page. What kind of data are we talking about, application settings or user generated files?


There is no user generated application... there are only settings files.

Could you please tell me what is the command if I want to stop users from selecting a different folder?


Originally posted by Animaether
You can't say "Microsoft didn't change anything" and then follow that up with "since Vista, new users aren't automatically put into the Administrators group"; that -is- a change.
Sure, if you want to split hairs, be my guest. Look, you're kind of missing the point here. Microsoft didn't change anything in the way $PROGRAMFILES is designed to be used. The fact that Vista fails at user-writing to $PROGRAMFILES more gracefully than XP did, well that's not a change, that's just better "dealing with coders who don't comply with specifications".

adriantc, you can add a leave function to the DIRECTORY page, and throw a MessageBox warning there if $INSTDIR isn't what it should be anymore.

Could you please explain in more detail. I made the installer using the HM NIS Edit and until now it was just enough for me; I didn't need to go into more detail then the very basic.


Declare a LEAVE function after the declaring the DIRECTORY page (see MUI2 readme). Then in the leave function, you can do something like:


${EndIf}