martyl@rocksvax.UUCP (Marty Leisner) (05/22/87)
I'm using DOS 3.2 and various ATs at work, and I'm not concerned about portability to older DOS 2.x versions. The information I'm looking for pertains to a shell process which is spawning other programs, handling pipes and redirection, etc. One of the problems I have is how to obtain the identity of stdin/ stdout/stderr. In order to preserve the identities of stdin/stdout/stderr, I now dup these when the shell starts up to preserve the identities. The initial version of this shell (the Dr. Dobb's sh) assumes the user is sitting a /dev/con and reopens these. But I'm using my PC off the COM port connected to a windowed workstation with a window for the PC. Also there isn't a /dev/tty device to reopen coming out of the redirection. The problem is the duped streams are inherited by the child process. There are a number of plausible solutions -- none seems to be built into dos. Among these are: 1) an impelmentation of fcntl(2) to change properties of an open fd (handle) -- Microsoft and Aztec C don't seem to have this built into the function libraries they provide -- I don't see a dos interrupt to do it. Is it possible? 2) Determine the identity of the open file handle. I suppose the Unix way of doing this would involve doing an fstat on the file descriptor, obtaining the device and inode numbers and figuring which file had these numbers. Seems pretty hard. 3) An implementation of fork(2). This is probably a most interesting exercise considering how ill-defined DOS seems to be. It also seems to magically solve all these shell problems with handling pipes and redirected i/o. I've done a little preliminary thinking of how to fork() under DOS -- anyone have a working implementation? It seems fork would need to: 1) get a new psp (Undoc function 55H or 26H)? 2) allocate space for new process 3) copy image into allocated space 4) Update _dsval and _csval (Aztec's way of defining the current code segment and data segment) 5) Somehow being able to magically come out of the fork in the child process and the parent process in an acceptable fashion 6) The child would reopen whatever streams are necessary and then exec the new process. It also seems reasonable to be able to implement memory resident pipes in a fairly straightforward way. I'm thinking along the lines of a PIPE device which could possibly manage some buffers and control the scheduling algorithm of which process is running -- i.e. give each process connected to the pipe someprocessing time when there's pending data in the pipe. Any comments on feasibility/usefulness/past experience along these lines would be welcome. marty leisner xerox corp. leisner.henr@xerox.com martyl@rockvax.uucp 1) somehow force DOS to create a new PSP. (undoc function 55H?) 2) allocate memory for image of new code and data space 3) copy code and data space 4)