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