Suggestions for gpgme on mingw-w64

[Werner Koch]

On Fri,  4 Sep 2015 12:42, jeroen.ooms at stat.ucla.edu said:

> ## w32spawn

> home directory, and then dynamically loads them when needed. Therefore
> _gpgme_get_inst_dir() returns the installation directory of the main R
> software, which is not writable by the user.

You should really try to use the gpgme DLL and not link it statically -
this will return the installation directory of the DLL.  However, I know
that this is sometimes not easy to achieve.  

> It would be really nice if we could manually set the path to
> gpgme-w32spawn.exe, for example with a runtime environment variable or
> via gpgme_set_global_flag("gpgme-w32spawn", ...) or something similar.

Well, if that is really required it can be done.  Dymnamically loaded
code has a lot of problems which we can fortunately solve on Windows by
using a DLL.  If you don't see a chance to use a DLL, such an option can
be added.

> Alternatively gpgme could search the PATH as well.

No.  That may turn up an incompatible versions of the helper and we get
trouble analyzing bug reports.

> One final suggestion is that the error message in
> _gpgme_get_w32spawn_path could be improved a bit. I spent a lot of

Good idea.

> ## finding gpgconf
>
> There are several methods described to find gpg, and none of them
> worked on my windows 64 system, though I have a completely standard
> gpg4win installation.

Thing will be better with GnuPG 2.1 - the installer uses a weel-known
installation directory and the latest gpgme knows about it and only
falls back to the standard gpgwin install directories if no 2.1 is
installed.

> Finally, the find_program_at_standard_place() function in w32-util.c
> checks CSIDL_PROGRAM_FILES (which corresponds to c:/program files/).
> However on a windows 64 machine, the default directory of gpg4win is
> actually in CSIDL_PROGRAM_FILESX86 (which corresponds to c:/program
> files (x86)/), so gpgme should check this dir as well. After I changed

Interesting.  Does that mean that for a 64 bit process, the
CSIDL_PROGRAM_FILES is different for than for a 32 bit process?  I guess
that makes sense.

Okay to check CSIDL_PROGRAM_FILESX86 after CSIDL_PROGRAM_FILES on a 64
bit Windows?  For my understanding this would also prefer a 64 bit
version of GnuPG (which does not yet exist) over a 32 bit version.



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.