Date: Sun, 28 Feb 1999 14:43:58 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Alain Magloire cc: djgpp-workers AT delorie DOT com Subject: Re: inetutils In-Reply-To: <199902262327.SAA11493@mccoy2.ECE.McGill.CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com On Fri, 26 Feb 1999, Alain Magloire wrote: > I don't have POSIX.1g at end to see the rationale but it seems, to me, > that spawning without being able to redirect the file descriptor > of the child, restrict the utility of spawn(). There's probably some sort of misunderstanding here (at least on my part ;-). `spawn' *does* allow to redirect the standard handles of the child program, it just requires that the parent redirects its handles for that; the child then inherits those redirected handles. Since the parent doesn't resume until the child exits, it doesn't need to worry about its standard handles during the time the child program runs. When the child does return, the parent simply restores its handles to previous values. `dup' and `dup2' *do* work in DJGPP, exactly like you'd expect. > So in other words, you're saying, it is not possible to port > the inetutils servers, that rely on the operating system to provide > some sort of multitasking via the system calls(fork/spwan,...). > However it is possible to do it on Windows but not with djgpp framework ? Since the multitasking is provided by Windows (which *can* be called an operating systerm ;-), it is exactly like on Unix, except that the way I described to run programs asynchronously doesn't include inheritance of standard handles and environment variables, so these must be treated separately and specially (in this case only).