L.Allan-pbio wrote:
I tested with a limited user account on WinXp-Sp2, and based on that
modified the HkcuVsHklm test a smidge to detect whether the person
using the installer has Admin priv, or just limited user priv.
Good work!
Based on this, the custom page's PreShow function can decide whether
or not to show the custom page at all (won't show it for limited user).
This probably doesn't address all the issues, but maybe enough to not
punt quite yet and insist on Admin priv?
If you do the leg work, I'll incorporate it. But at some point we need
to do a release. And at that point whatever is solid will make the cut
and be used. We can still work on it for the next release.
My impression is that a limited user can read HKLM. I'm pretty sure
that nsis has the capabilit to detect WinNt4/2k/Xp vs Win98, but I
haven't used that (may be a plugin).
There is a function in WriteEnvStr.nsh, which we use for SWORD_PATH,
called isNT. So if it returns that it is not "NT" and the page is not
offered.
Since we need to assume that if a user does not have admin privs that
they must do a limited user install, should we make the reverse
assumption, that if they can do admin install that we will do it.
However, you may be correct that a limited user will have problems
writing to C:\Program Files ..... which presents a big problem. On my
test computer, the C:\Program Files was created by my normal Admin
account, which may prevent a subsequent limited user account from
writing to it .... that might not be the case if the C:\Program Files
was created on a computer that didn't have a previous Admin account
established. Shucks.
I don't think that it matters. If it can't be written to on some
machines, but because of how the user upgraded to their current os, then
we shouldn't use that location.
That would be a show stopper. There must be an alternative location for
a limited user.
There will probably be similar issues with SWORD_PATH ... a limited
user can probably set this environment variable for just themselves,
not all users.
Hopefully, WriteEnvStr has all that figured out. But we should check.
Here are revised functions ... the only other change is swapping the
"state" in the .ini file for Field 1 and Field 2. At the following
link from the nsis function, the principal nsis developer describes
how to detect admin priv mode vs limted user mode:
http://forums.winamp.com/showthread.php?s=&threadid=122968
I'll add this into my working copy.
Function .onInit
ClearErrors
StrCpy $HkeyChoice "all"
WriteRegStr HKLM "SOFTWARE\CrossWire\The SWORD Project" "HkcuVsHklm"
"$HkeyChoice"
IfErrors LimitedUserDetected AdminLevelDetected
LimitedUserDetected:
MessageBox MB_OK "Limited User Detected"
StrCpy $HkeyChoice "current"
GoTo PrivLevelDetected
AdminLevelDetected:
MessageBox MB_OK "Admin User Detected"
DeleteRegValue HKLM "SOFTWARE\CrossWire\The SWORD Project"
"HkcuVsHklm"
DeleteRegValue HKCU "SOFTWARE\CrossWire\The SWORD Project"
"HkcuVsHklm"
PrivLevelDetected:
!insertmacro MUI_INSTALLOPTIONS_EXTRACT "HkcuVsHklm_CustomPage.ini"
FunctionEnd
Function PreShowInstallChoices
StrCmp $HkeyChoice "current" 0 ShowInstallChoices
SetShellVarContext current
Abort
ShowInstallChoices:
!insertmacro MUI_HEADER_TEXT "$(TEXT_IO_TITLE)" "$(TEXT_IO_SUBTITLE)"
!insertmacro MUI_INSTALLOPTIONS_DISPLAY "HkcuVsHklm_CustomPage.ini"
FunctionEnd
----- Original Message ----- From: "DM Smith" <[EMAIL PROTECTED]>
To: "SWORD Developers' Collaboration Forum" <sword-devel@crosswire.org>
Sent: Monday, February 13, 2006 10:22 AM
Subject: Re: [sword-devel] BibleCS Installer: HKCU vs HKLM
L.Allan-pbio wrote:
Regarding use of HKCU vs HKLM (split from general Installer thread
to be focused on this issue alone) :
Here is some sample code for a custom page allowing choice of "Just
this user" and "All Users". It is pretty stripped down just to
illustrate the basics of how it works.
I played with this code and it works as advertised.
However, in trying to get it to work, I ran into lots of other
questions/issues.
Basically different scenarios that could happen on a machine raised
questions on what should happen:
1) Reinstall (i.e. user runs install a second time without
uninstalling first) and instead of choosing HKCU, which was the
install, now chooses HKLM
2) The user only has limited install privs and chooses HKLM.
3) The user tries to install 1.5.8 as HKCU, but the application has
already been installed as HKLM.
4) User upgrades (e.g. to > 1.5.6) from a prior HKCU (e.g. <= 1.5.6)
and chooses:
a) HKCU, or
b) HKLM
5) User upgrades (e.g. to > 1.5.8) from a prior HKLM (e.g. 1.5.8) and
chooses:
a) HKCU, or
b) HKLM
I am sure there are others.
The other question I had was what should happen for a limited user
install?
Can the user install to C:\Program Files?
The application writes to the installation dir for user prefs,
install sites, modules and the like. Will this work for a limited user?
If the application is installed to a shared workstation by an
administrator and the first administrator runs the program and
changes the layout to what they like, won't that be the layout that
the next administrator sees?
I also ran into a problem trying to establish $INSTDIR.
The way it should work is that the installer sets a default.
Then it looks for a prior HKLM installation and if it is present,
then the default is set to that.
Then it looks for a prior HKCU installation and if it is present,
then the default is set to that.
And it should note whether HKLM or HKCU was used to for the default
and use that as the default root when presenting to the user.
This is so that SetShellVarContext can be called appropriately (all
for hklm and current for hkcu).
NSIS provides the following commands to help:
To establish the default:
InstallDir default\dir\path
To reset the default to the prior installation, if found:
InstallDirRegKey ROOT subkey keyname
However, these cannot be in a section or in a function.
And InstallDirRegKey does not take SHCTX, forcing using either HKCU
or HKLM (or any other explicit root).
I tried calling InstallDirRegKey twice once with HKLM and once with
HKCU, but the second call is ignored upon compilation.
The further problem is that even if it could be called twice, the
value of $INSTDIR cannot be examined at each point to determine which
root to use, as StrCmp and StrCpy cannot be used outside of functions
and sections.
What this would leave is not using InstallDir and InstallDirRegKey,
but in the function .onInit, simulate this behavior and establish
INSTDIR via StrCpy
and then call SetShellVarContext to set the default.
The other gotcha is that under section D.2 of the NSIS manual it
clearly states that HKCU is available to Add/Remove Programs for
NT4/2000/XP and that HKLM needs to be used for earlier systems.
Even though the HKCU may exist prior to these, it probably should not
be used at all. So this would mean adding conditional logic into
whether the page is shown or not.
Anyway, I think this is a big hurdle and is better left to a later
date. I think for now we should assume that the user is an
administrator and that all users share the one configuration.
(I haven't tested with a "limited user" account to see what happens.
I suppose that could be detected with Contrib\UserInfo\UserInfo.nsi
and only allow "current" and don't even show the custom page ... my
impression is that a "limited user" can still read HKLM)
;*************** ini file ************
# HkcuVsHklm_CustomPage.ini
[Settings]
NumFields=2
[Field 1]
Type=RadioButton
Text=Install for just this user
Flags=NOTIFY|GROUP
State=0 ### Was 1 .... if shows custom page, must be admin
Left=0
Right=-10
Top=0
Bottom=12
[Field 2]
Type=RadioButton
Text=Install for all users on this computer
Flags=NOTIFY|NOTABSTOP
State=1 ### was 0 ... if shows custom page, must be admin
Left=0
Right=-10
Top=20
Bottom=32
********** Installer ***************
!include Sections.nsh
!include "MUI.nsh"
Var HkeyChoice
Page custom PreShowInstallChoices LeaveInstallChoices ": Just this
user or all users"
!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_LANGUAGE English
;--------------------------------
; Installer attributes
Name "Modern UI Test"
OutFile HkcuVsHklm.exe
InstallDir "$PROGRAMFILES\Modern UI Test"
InstallDirRegKey HKCU "Software\Modern UI Test" ""
LangString TEXT_IO_TITLE ${LANG_ENGLISH} "CrossWire family of
applications."
LangString TEXT_IO_SUBTITLE ${LANG_ENGLISH} "Explanation about
choosing 'Just this User' vs 'All Users' goes here."
Function .onInit
DeleteRegValue HKLM "SOFTWARE\CrossWire\The SWORD Project"
"HkcuVsHklm"
DeleteRegValue HKCU "SOFTWARE\CrossWire\The SWORD Project"
"HkcuVsHklm"
StrCpy $HkeyChoice "current"
!insertmacro MUI_INSTALLOPTIONS_EXTRACT "HkcuVsHklm_CustomPage.ini"
FunctionEnd
# Installer sections
Section -Main WriteFiles
SectionEnd
Section -post WriteRegistryEntries
WriteRegStr SHCTX "SOFTWARE\CrossWire\The SWORD Project"
"HkcuVsHklm" "$HkeyChoice"
SectionEnd
Function PreShowInstallChoices
!insertmacro MUI_HEADER_TEXT "$(TEXT_IO_TITLE)" "$(TEXT_IO_SUBTITLE)"
!insertmacro MUI_INSTALLOPTIONS_DISPLAY "HkcuVsHklm_CustomPage.ini"
FunctionEnd
Function LeaveInstallChoices
; At this point the user has either pressed the Next Button or one
of our custom RadioButtons
; We find out which by reading the "Settings" field from the INI file
!insertmacro MUI_INSTALLOPTIONS_READ $0 "HkcuVsHklm_CustomPage.ini"
"Settings" "State"
StrCmp $0 0 NextButtonPicked
StrCmp $0 1 JustThisUser
StrCmp $0 2 AllUsers
Abort ; Return to the page to allow further choices
JustThisUser:
StrCpy $HkeyChoice "current"
Abort ; Return to the page
AllUsers:
StrCpy $HkeyChoice "all"
Abort ; Return to the page
NextButtonPicked:
StrCmp $HkeyChoice "current" 0 UseAll
SetShellVarContext current
GoTo ChoiceDone
UseAll:
SetShellVarContext all
ChoiceDone:
FunctionEnd
Function .onInstSuccess
ReadRegStr $0 SHCTX "SOFTWARE\CrossWire\The SWORD Project"
"HkcuVsHklm"
MessageBox MB_OK "Hkey Choice: $0"
FunctionEnd
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
