To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Unimplemented functions in library
Date:	Tue, 24 May 94 10:32:36 +0300
From:	eliz AT is DOT elta DOT co DOT il

 Hi,

 There are several functions which exist in the library only to return an
error code when called.  Examples are fork()/vfork(), pipe(), wait(), and
others.  It seems to me that returning an error condition in these cases
might not always be the wisest choice, at least for the above examples.  It
*is* true that these calls make no sense in the DOS environment, but one of
the main reasons for DJGPP is to aid porting existing software to DOS platforms,
right?  Thus, it would be nice if the stubs for these functions minimize the
amount of #ifdef's required to convert the usual fork()/exec() paradigm into
valid DOS code.  Based on my recent experience of porting GNU Diffutils to
DJGPP, I would suggest the following behavior:

	fork() and vfork() should return 0, because under DOS, the ``child''
                           and ``parent'' parts of code should both be done;

	pipe()             should return 0 and either (a) do nothing with its
	                   argument, or (b) [which is better] save STDIN and
	                   STDOUT in its argument by calling dup(), create 2
	                   temporary files, and redirect STDIN and STDOUT to
	                   them;

	wait()             should return immediately with the error code and
	                   exit status of the last call to spawn* function.

  This would reduce the necessary changes to:

	substitute spawn* for exec* call;
	restore STDIN and STDOUT (after spawn returns) with dup2, using file
	      descriptors saved by pipe();
	open temporary file (written by subsidiary program) for reading.

	Opinions, anyone?

	Eli Zaretskii

- Raw text -