From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Werner Koch Newsgroups: gmane.emacs.devel Subject: Re: pipe Date: Sat, 14 Mar 2015 12:51:00 +0100 Message-ID: <87d24bdcgr.fsf@vigenere.g10code.de> References: <83twxp2mew.fsf@gnu.org> <87h9tp3wsp.fsf-ueno@gnu.org> <87wq2kd5je.fsf@vigenere.g10code.de> <83d24c2c2p.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1426334213 26841 80.91.229.3 (14 Mar 2015 11:56:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Mar 2015 11:56:53 +0000 (UTC) Cc: ueno@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 14 12:56:47 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YWkgP-000722-Ie for ged-emacs-devel@m.gmane.org; Sat, 14 Mar 2015 12:56:45 +0100 Original-Received: from localhost ([::1]:40463 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YWkgO-0000cI-Ds for ged-emacs-devel@m.gmane.org; Sat, 14 Mar 2015 07:56:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YWkg9-0000cD-6B for emacs-devel@gnu.org; Sat, 14 Mar 2015 07:56:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YWkg0-0004S4-7r for emacs-devel@gnu.org; Sat, 14 Mar 2015 07:56:29 -0400 Original-Received: from kerckhoffs.g10code.com ([217.69.77.222]:33828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YWkg0-0004RE-1a for emacs-devel@gnu.org; Sat, 14 Mar 2015 07:56:20 -0400 Original-Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YWkfy-00048Q-Ul for ; Sat, 14 Mar 2015 12:56:18 +0100 Original-Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YWkaq-00061U-GY; Sat, 14 Mar 2015 12:51:00 +0100 Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Eli Zaretskii , ueno@gnu.org, emacs-devel@gnu.org In-Reply-To: <83d24c2c2p.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 14 Mar 2015 10:54:54 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 217.69.77.222 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183867 Archived-At: 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.