Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Message-Id: <200003021905.NAA09040@hp2.xraylith.wisc.edu>
To: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: problem with fork/exec in Cygwin DLL called from non-Cygwin E XE 
In-reply-to: Your message of "Thu, 02 Mar 2000 13:32:41 EST."
             <20000302133241 DOT F20207 AT cygnus DOT com> 
Date: Thu, 02 Mar 2000 13:05:46 -0600
From: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>

Chris Faylor <cgf AT cygnus DOT com> writes:
> 
> No, not at all.  I don't want to add to the current ugly dynamic DLL
> handling code though.  It seems incredibly complicated (to me) for
> something that AFAICT should be relatively simple.
> 
> Both Mumit and I have banged on the code but neither of us have been
> brave enough to streamline or simplify it.

The last time we went through this code, the consensus (then) was that we
won't be able to support subprocess handling via fork/exec in Cygwin DLLs 
that are dynamically loaded, which is the case when it's loaded via
Excel. Note that this non-working set includes exec* family as well, and
what works is the spawn* family of routines, which can replace *some*
instances of fork/exec pair.

Regards,
Mumit

ps: I'd love to be proven grossly wrong in this case!