Re: pipe

[Werner Koch <wk@gnupg.org>]

On Sat, 14 Mar 2015 09:54, eliz@gnu.org said:

> Thanks, but where do I see the source of that wrapper?  I tried the
> gpg Git repo, but I don't think I see it there.  Did I miss something?

It is in gpgme, a library interface to gnupg:

git://git.gnupg.org/gpgme.git

The wrapper is src/gpgme_w32spawn.c and the code in gpgme is in
src/w32-io.c (and src/w32-util.c).  However if you also link to glib the
used code is w32-glib-io.c.  

> And anyway, how does this wrapper solve the problem of invoking gpg
> with the --status-fd, --command-fd, and --attribute-fd options?  IOW,
> how can the invoking program pass file descriptors on the gpg command
> line, and be sure gpg will use the same files/devices as the caller?

Use gpgme ;-)

Simply use "--status-fd HANDLE" or if gpg expects a filename use the
option --enable-special-filenames which interprets filename of the form
"-&N" as the handle N.

Under Windows we use a HANDLE and not a file descriptor.  Thus ReadFile
and WriteFile is used.  Using the libc file handles is not a good idea.
The problem in gpg is that this is all mapped to an "int" and thus we
can't easily change this to a 64 bit Windows because a HANDLE is a
pointer and sizeof(void*) > sizeof(int).  There are too many different
objects in Windows with the same function but they are not all the
same.  Using a kernel object like HANDLE is the only clean solution.

> I'm guessing you actually mean "file handles", not "file descriptors"
> here.  The latter are small integer numbers, like 0 for standard

What I mean is that WindowsCE(!) has no global file descriptor table.
There is only the per-process one.  But WindowsCE is entirely different
form Windows.  They only share the the same API with lot of properties
not implemented.

> like 6 be passed to gpg -- AFAIK it will end up connected to nothing
> on the child side.  (There's an undocumented trick in the MSVC runtime

You create a pipe using CreatePipe and make one end inheritable using
DuplicateHandle.  See gpgme/src/w32-io.c - it is a bit complicated due
to the fact that you can't select (WaitForMultipleObjects) on HANDLEs.

IIRC, with Windows 7 there are newer APIs which could be used instead of
the select emulation using I/O threads.

> that allows this to work, but AFAIK that doesn't work with MinGW, only

Nope.  It is all specified by the Win32 API.  If you are interest in
details on this I suggest to read Hart's Windows System Programming.  I
consider this the Windows counterpart to APUE.


Shalom-Salam,

   Werner


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