[sword-devel] BibleCS Installer: HKCU vs HKLM

[DM Smith]

L.Allan-pbio wrote:
>> 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.
>
> I did some more research, and the more you look, the more complicated 
> it seems to get. I'm ready to punt and proceed with the assumption 
> that they need admin priv ... to both install and run.
>
> The problem doesn't look like it will go away. My impression is that 
> more and more the guidance is to run with least privilege because that 
> prevents most malware from being able to do their damage.

I'll "hide" the changes or save them off so we can revisit in a later 
release. The only thing left after that is to conditionally remove the 
installed modules when the last CrossWire family member is uninstalled 
as indicated by the HKLM/Software/CrossWire key.

>
>>> 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.
>
> I didn't find any .... that does seem like a show-stopper. The WinXp 
> Logo requirement calls for installation to C:\Program Files, and being 
> able to run as a limited user. Files like userpref.conf, options.conf, 
> and other writable .conf files are supposed to go in C:\Documents and 
> Settings\[CurrentUser]. It may be that the Microsoft .msi installer 
> would need to be used to accomplish that.

NSIS has variables for those areas (it is actually [drive]:\Document and 
Settings\[Current User]\Application Data\[my app])
but unless the SwordAPI changes to look there it won't work to put the 
files there.
>
>
> If we didn't have 1.5.6 (and earlier) legacy, it perhaps might be 
> worth wrestling with, but reinstalls to the existing location put the 
> difficulty/effort/complexity beyond something I have 
> time/experience/aptitude to work on. Sorry (and also for bringing up 
> the issue without realizing the implications and thus slowing down 
> progress).

It is the challenge to dig deeper and not accept the simple or obvious 
that leads to better solutions.
I learned a lot about NSIS that I will be able to use again.
No need for apology.

>
>>> 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.
>
> I think you are correct.