Creating a Win32 Library for GPG?

[Oliver Nittka]

i would like to add my $0.02.

although my preferred platform is linux, most of my administration and
programming takes place on windows, as all of our desktops run win95/98
and nt4.0.
i would be *very* happy if there was a possibility to integrate gnupg
in at least netscape mail and outlook. i already *was* very happy to
see the mingw-compiled version with entropy.dll which made it possible
to do at least some basic en-/decryption on windoze.

on unix, i perfectly agree with the statement "keep it the KISS way:
fork and pipe", because on unix, this works pretty well.

i wouldn't say the same for windoze, for several reasons

- fork (or ShellExec in windows or whatever) has significantly more
  overhead than on unix. calling gpg.exe two or three times per
  decryption (as e.g. mailcrypt does) would  slow things down
  drastically and make my harddisk sing ;-)
- there are differences between "console applications" and "windows
  applications". while, on one hand, a "dos box" pops up annoyingly
  for console apps, on the other hand you haven't got stdin/out with
  windows apps. i don't know how often this kept me from calling other
  apps in my programs, but each time it was one too often.
- but this is not only for stdin/out. the whole concept of piping
  doesn't work as you would expect. e.g. i couldn't get mailcrypt to
  decrypt under nt-emacs, because "gpg --status-fd=3 3>statusfile"
  leaves the statusfile empty (with cygwin bash; cmd.exe gives
  errors). this could possibly be fixed by compiling with cygwin, but
  then other problems will arise.

all in all, i would say the "fork and pipe" - approach is a major PITA
under windoze. i was already looking into pgg by Michael Roth, but
this one just calls gpg, so it would suffer the same drawbacks.

how would you think about putting all of the "engine" in a libgpg.so /
gpg.dll which can then be used from other applications (e.g. gpg /
gpg.exe) which are just a frontend to the crypto-functions.

i don't think this would be *that* much work (although it may mean to
completely restructure the sources), and i'm willing and able to help,
especially on the win-parts.

any comments very welcome.

  -- oly
-- 
Oliver Nittka              | nittka at esem.com
ESEM Grünau GmbH & Co. KG  | http://www.esem.com
Dornierstraße 6            | phone: +49 7544 9583-25
88677 Markdorf / Germany   | fax:   +49 7544 9583-60