Archive: Is there a InstallDirRegKey analog for $APPDATA
Is there a InstallDirRegKey analog for $APPDATA
I am updating an existing installer for Vista/Windows 7 which currently was designed for XP and below. For the installation directory I use this code:
InstallDir "$PROGRAMFILES\${PRODUCT_NAME}"
>InstallDirRegKey HKLM "${PRODUCT_DIR_REGKEY}" ""
For the application data directory I use this:
StrCpy $ApplicationDataPath $APPDATA${PRODUCT_NAME}
Is there an analog to InstallDirRegKey for the application data path?
No but you can make your own by using the registry functions in .oninit
Do you know where in the registry the information read by InstallDirRegKey is located? I have been unable to locate it. My installer is finding it, but where it is finding it I don't know. If it is any help I currently have these lines which might be a clue:
!define PRODUCT_DIR_REGKEY "Software\Microsoft\Windows\CurrentVersion\App Paths\BPQ32.exe"I remove the entry in the uninstall:
>.
>InstallDirRegKey HKLM "${PRODUCT_DIR_REGKEY}" ""
>.
>WriteRegStr HKLM "${PRODUCT_DIR_REGKEY}" "" "$INSTDIR\BPQ32.exe"
DeleteRegKey HKLM "${PRODUCT_DIR_REGKEY}"
Incidentlaly in Vista/Windows 7 I will be installing for the current user, so is it safe to assume that for those HKLM should be HKCU?
Where? You are telling it where to look with InstallDirRegKey lol
Yes you are right of course! What is contained there in the registry is:
default REG_SZ C:\Program Files\BPQ32\BPQ32.exe
I see now that the command InstallDirRegKey will remove BPQ32.exe leaving just the path. Apparently it was pointless to include \BPQ32.exe in the WriteRegStr to start with.
Thanks again for your help, it has been very valuable for one just learning!
This it would seem would be written in the registry at the HKLM root key, however what is actually happening is that for XP it is written at HKLM, but for Windows 7 it is written at HKCU.
WriteRegStr HKLM "${PRODUCT_DIR_REGKEY}" "" "$INSTDIR\BPQ32.exe"
Any idea of why this is happening?
Could be that win7 is "fixing" your installer because it's trying to write to HKLM without having admin access. Add "requestexecutionlevel admin" and use the userinfo plugin in .onInit to verify that you have admin (and throw an error and quit if you don't).
I already had "requestexecutionlevel admin".
I added the following in .onInit:
# call userInfo plugin to get user info. The plugin puts the result in the stack
userInfo::getAccountType
# pop the result from the stack into $0
pop $0
# compare the result with the string "Admin" to see if the user is admin.
# If match, jump 3 lines down.
strCmp $0 "Admin" +3
# if there is not a match, print message and return
messageBox MB_OK "not admin: $0"
return
# otherwise, confirm and return
messageBox MB_OK "is admin"
When running the created installer it reports "is admin".That was kind of ugly...here is the actual code I am using to do the test:
The resulting messagebox displays "is admin"userInfo::getAccountType Check to see if we have gained administrative priv.
pop $0
${If} $0 == "Admin"
messageBox MB_OK "is admin"
${Else}
messageBox MB_OK "not admin: $0"
${Endif}
Use Process Monitor to see what happens to the reg write...
Originally posted by Ron.StordahlNote: The above code is correct, but only for testing purposes. However, you need to use this code in your final installer as well, because 'requestexecutionlevel' does nothing if UAC is disabled, or on older OS versions... For that, you need to actually call the abort (or quit) command if the user isn't admin.
here is the actual code I am using to do the test:
userInfo::getAccountType Check to see if we have gained administrative priv.
pop $0
${If} $0 == "Admin"
messageBox MB_OK "is admin"
${Else}
messageBox MB_OK "not admin: $0"
${Endif}
I am using the following code to install a DLL:
dll $SYSDIR
>
Is it safe to say that the user who is running this installer will need Administrator Privileges to install that DLL? If so, then I will use the 'code' to test if the user has such privileges and if not, I will issue a message to that effect and abort.
Originally posted by Ron.StordahlYes. $SYSDIR is a protected directory, so you need admin privileges to write there.
I am using the following code to install a DLL:
Is it safe to say that the user who is running this installer will need Administrator Privileges to install that DLL?dll $SYSDIR
>
How far back does that go? XP, W2K, or is this just Vista and later?
All NT operating systems (NT, 2000, XP, Vista, etc..) have a protected $SYSDIR folder. The same applies to $WINDIR and $PROGRAMFILES, among others. (This means that if your default install directory is in program files and you don't check for admin access, your installer is kind of defective.)