[Pcgen-trackers_code] [JIRA] Commented: (CODE-124) Improve Windows 7 support

[James D. (JIRA) <ji...@pc...>]

    [ http://jira.pcgen.org/browse/CODE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10495#action_10495 ] 

James Dempsey commented on CODE-124:
------------------------------------

The $LOCALAPPDATA constant can be used as per the discussion below, see http://nsis.sourceforge.net/Docs/Chapter4.html#4.2.3

> Improve Windows 7 support
> -------------------------
>
>                 Key: CODE-124
>                 URL: http://jira.pcgen.org/browse/CODE-124
>             Project: Code
>          Issue Type: New Feature
>          Components: Installer
>            Reporter: Andrew Maitland
>
> [pcgen] UAC and Changing Windows Default Install Path (was Re: Creating Monster Kit)
> From: dynamotwain <dynamotwain@...
> JAMES
> Agreed. The installer we use (NSIS) knows about these locations. I'm 
>  also one that would never use a top level folder - I have  a number of 
>  specific use folders even on XP for these sorts of things (C:\Utils, 
>  C:\Games etc). PCGen is already capable of handling most of its files 
>  distributed across locations, e.g. data does not need to be directly 
>  under the install directory but system does.
>  
> [snip]
>  Yes the C:\pcgen *default* is a 10 minute job as opposed to a couple of 
>  days to do the proper job above.
>  
> - DYNO
> Unfortunately, the hack proposed above will not work on Windows 7 as file-permissions have gotten stricter outside of user profiles.
> 1. With Windows 7, default NTFS filesystem permissions for the boot drive (i.e. C:\) are writable by Administrators only for security reasons.
> 2. Any folder created defaults to inheriting the parent folder's Access Control List unless an ACL is explicitly specified when creating the folder.
> Thus, installing the program to C:\PCGen, C:\Games\PCGen, or C:\Programs\PCGen will inherit the permissions of C:\ and will require Administrative permissions to change these files on Windows 7, and will not solve this problem.
> Only very few directories are not subject to this restriction: FOLDERID_ProgramData, %USERPROFILE%, and non-boot drives without Windows installations (i.e. external hard-drives)
> The easiest way to work around this (with no coding changes other than to the installer) is to make all installations a "per-user" installation. In this scenario, everything is installed within a particular user's profile, so Admin privileges aren't even needed to install the app.
> With Windows 7, there is a new special folder FOLDERID_UserProgramFiles = %LocalAppData%\Programs
> into which programs may be installed. %LocalAppData% is a subdirectory of the user's profile, so they will always have permission to write to this folder, no elevation needed. While FOLDERID_UserProgramFiles does not exist on Vista, installing to %LocalAppData%\Programs would work on both Vista + Win7/
> A more complete solution would involve one of the following to support system-wide installations:
> 1) Moving the OOC Installer to an external JAR with its own launch4j configuration and a Windows manifest requesting highestAvailable privledges (to prompt for UAC elevation). If the data directory is still not writable (because the user isn't an administrator), then only installation to vendordata (in the user's profile) should be allowed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.pcgen.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira