w32 installation paths (was: OK, here goes trouble... re c:\gnupg)
Werner Koch
wk at gnupg.org
Tue Nov 9 17:35:17 CET 2004
On Tue, 9 Nov 2004 08:19:19 -0500 (EST), Mark H Wood said:
> The difficulty arises because some people want the MS Windows version to
> work like every other MS Windows application, and some want it to work
> like every Unix application. Your proposed behavior is probably the best
For a Unix like environment, using a Cygwin version of gpg is probably
best because it will better play together with other Unix tools.
> OS, because the conventions are different. On Unix-alikes it should be
> $HOME/.gnupg, and on MS Windows it should be %ApplicationData%/gnupg/gnupg
> (the first "gnupg" is the "vendor" and the second the product).
So what you are saying is that we should not use the registry to
locate the home directory but to use an environment variable instead.
Just checked it on W2000: Running a shell does not show "ApplicationData"
but only "APPDATA" - does this depend on the Windows versions? hat
about W98 and such; I guess they don't define these variables at all?
> where to install itself, and the default should be
> %ProgramFiles%\vendor\product . Further, no per-user data should *ever*
> be stored there, unless the user insists; user settings go in the profile,
Okay. ProgramFiles is available.
> as indicated above, unless the user says otherwise. (OTOH I usually try
> to keep layered products *off* of %SystemDrive% and complain bitterly when
> the installer doesn't let me change the install path.)
Noted, for a future installer based package.
> (I've shown the environment variables ApplicationData and ProgramFiles,
> but those paths should actually be fetched using the appropriate Shell
> APIs. Microsoft say that the variable names may be localized, but the API
> argument constants won't change.)
I see, any hints on the function name for this? I guess that
function needs to be dlopened to allow running under W98 etc.
> On MS Windows an executable can discover the path from which it was run,
> and that's probably the best way for the product to find its installed
> location. There's also a Registry key AppPaths somewhere in which the
You mean an installer should locate an existing installation by
running "gpg --version" and figure out its path? Makes sense to me.
> path should be stored if other applications need to find yours.
Does that mean we should add a key AppPath to the registry entry for
GnuPG, like:
[HKEY_LOCAL_MACHINE\Software\GNU\GNUPG]
"HomeDir"="C:\\GnuPG"
"gpgProgram"="C:\\GnuPG\\gpg.exe"
"AppPath"="C"\\GnuPG\\"
> I may be arguing for a lot of stuff that's already been done, because I
> only use GnuPG on Linux and haven't seen the MS Windows deployment. But I
I have virtually no experience with Windows administration so
appreciate any hints. To sum up how things should work:
1. Installation:
gpg and the other other executables should be installed in
%ProgramFiles%\GNU\GnuPG\ unless an existing gpg.exe has been
found or the user requested a different directory.
A Registry entry
[HKEY_LOCAL_MACHINE\Software\GNU\GNUPG]
"gpgProgram"="%ProgramFiles%\\GNU=GnuPG\\gpg.exe"
"AppPath"="%ProgramFiles%\\GNU\\GnuPG\\"
will be created. The question is whether %ProgramFile% is to be
sued or the expanded value. IRIC, W98 does not support the
expansion.
Question: Just entering "gpg" on the command line won't work then
becuase it is not listed in the PATH environment variable. What
the usual way to fix this?
2. Runtime
When gpg has been started it needs to locate its home directory.
The following algorithm will be used:
if option --homedir given
use that
else if env var GNUPGHOME set
use that
else if "HKEY_CURRENT_USER\\Software\\GNU\\GnuPG\\HomeDir" set
use that
else if env var %ApplicationData% set
use %ApplicationData%\\GNU\GnuPG\
else
use c:\\gnupg -- old default
This is not compatible to old versions but 1.4 is a new major
release and thus some changes are possible.
Any comments?
Werner
More information about the Gnupg-users
mailing list