Hi Jonathan,

Replying to a message of Jonathan de Boyne Pollard to Mike Burgett:

 JdBP>   Why not ?  What, specifically, does or does not happen ?

[ ... good tips deleted to save space ... ]

I was getting garbage on my DosRead's of the pipe, but have since rectified
the situation.  The major problem (I think) was that I neglected to dup
off, and close the stdout/stderr streams before trying to replace them with
the write end of the pipe. Major boo-boo.

Regarding fdopen (Mike Bilow's suggestion) I also found out that this does
work with a handle acquired from a API call, (You are right again Mike, as
usual :), while I didn't think it would.  (I seem to recall reading
somewhere, that the handles returned by the API calls weren't the same as
the handles used in the C RTL... but that must have been an earlier
version, or I'm thinking of a different OS...  though it would be nice if
this was explicitly documented somewhere (where I could find it. :) since I
do know, I've seen at least one C-RTL implementation on some OS somewhere,
where the file handles used by the non-buffered routines
(open/close/read/write) were only indexes into the array of FILE structs
maintained by the RTL, and *not* handles that worked with the underlying
system API....)

Anyway, now I've got my program working, which is a shim to sit between
binkley, and ppp, so I can limit ppp callers both in time per call, and
time per day, and observe binkley's pending forced events.

Next task, is to find ppp sources somewhere, so I can see if I can modify
it to produce a ppp that will accept hot com handles, instead of insisting
on opening the port itself. :)

Thanks!
Mike

--- FleetStreet 1.18+