delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/05/25/05:44:17

Date: Wed, 25 May 94 18:00:02 JST
From: Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Unimplemented functions in library

Eli <eliz AT is DOT elta DOT co DOT il> writes:
 Date: Tue, 24 May 94 10:32:36 +0300
   From: eliz AT is DOT elta DOT co DOT il
   X-Mts: smtp

    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:

[ interesting suggestions and consequences elided ]

	   Opinions, anyone?

	   Eli Zaretskii

Yeah.  Don't.  The problem is the term "DOS Platforms".  There are
several.  I use DV/X a lot, I've built a couple of special purpose
functions to do some of those jobs.  [None are stable enough to
publish, sorry.]  Maybe similar alternatives exist under Windoze.
They certainly do under OS/2 [not a "DOS platform," but it does do DOS
and DJGPP works under it.]
    Unless you've got a solution that would work as a Unix programmer
expects and uses the relevant features of each of the environments,
it's going to be more stuff for us to track down.  Better a weird
error message.  An alternative solution would be a "libDAU.a" ("DOS
Ain't Unix" library) containing process-like (and other) stuff that
doesn't really emulate Unix very well.  (For example, your pipe
solution doesn't permit the program to concurrently do real work, nor
ask for and get answers depending on intermediate results.  Once
you're in the pipe, you succeed or fail.)  Then you could link it in
to do the default fixes.  This would give the functionality you want
without confusing me, at the expense of an extra -lDAU for you.
    It may be a difference of philosophy, but I don't want "valid DOS
code", I want approximately portable code.  (I know there are a fair
number of non-portabilities even now in the DJGPP package.  But I
believe that the Ghostscript port to DJGPP and DV/X was accomplished
with a change in the GNU-oriented makefile, and a small change in the
dosfs.c file used by other dos systems!  No #ifdef __GO32__'s!  Also
no DOS capability, you *have* to use DV/X :-( )  I'd rather have the
#ifdefs to remind me of nonportabilities, rather than have programs
break (eg, a program that expects pipes to do true IPC will compile
and link OK in your scenario, then hang) silently.

+-----------------------------------------------------------------------+
|                           Stephen Turnbull                            |
|     University of Tsukuba, Institute of Socio-Economic Planning       |
|          Tennodai 1-chome 1--1, Tsukuba, Ibaraki 305 JAPAN            |
|        Phone:  +81 (298) 53-5091     Fax:  +81 (298) 55-3849          |
|               Email:  turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp                 |
|                                                                       |
|                Founder and CEO, Skinny Boy Associates                 |
|               Mechanism Design and Social Engineering                 |
| REAL solutions to REAL problems of REAL people in REAL time!  REALLY. |
|                      Phone:  +81 (298) 56-2703                        |
+-----------------------------------------------------------------------+

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019