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! 

- Raw text -