Xref: utzoo alt.msdos.programmer:309 comp.binaries.ibm.pc.d:4165 comp.sys.ibm.pc:33227
Path: utzoo!utgpu!watmath!att!ucbvax!agate!usenet
From: hughes@math.berkeley.edu (Eric Hughes)
Newsgroups: alt.msdos.programmer,comp.binaries.ibm.pc.d,comp.sys.ibm.pc
Subject: Re: Creating your own stream
Message-ID: <1989Aug15.190814.26661@agate.berkeley.edu>
Date: 15 Aug 89 19:08:14 GMT
References: <1961@ptolemy.arc.nasa.gov>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: hughes@math.berkeley.edu (Eric Hughes)
Followup-To: alt.msdos.programmer
Organization: UC Berkeley Math Dept
Lines: 57
In-reply-to: raymond@ptolemy.arc.nasa.gov (Eric A. Raymond)

In article <1961@ptolemy.arc.nasa.gov>, raymond@ptolemy (Eric A. Raymond) writes:
>That is, given a set of primitive I/O functions, can I create a
>file-like device which will call these routines?  Then I can redirect
>I/O as I please.
>
>For instance:
>    my_stream = make_stream(my_getc, my_putc, my_printstring);
>    redirect_stream(stderr,my_stream);
>    printf(my_stream,"Hello World.\n");
>
>Unfortunately, me thinks this is highly system/compiler dependent (or
>rather language dependent; it's a snap in common lisp).

I know of no facility to do this directly, using the interface
that you specify.  That's not the whole story, however.

The DOS function call to do redirection is Int 21h, Function 46h.  It
takes as input two file handles, and the second handle is made to
point to the first one.  This is used in conjunction with the
duplicate handle call (function 45h) to be able to redirect back to
the original.  Germane to your question is that the OS support only
works on file handles, so in order to use this technique you'll have
to use a device driver.  And device drivers, I believe, are only
installable (legally, at least) at boot time, although I have 
heard that some have linked them in manually at the runtime of
an .EXE.

Nevertheless, you said you only needed a "file-like" device.  You
may be able to get this either by altering the system library 
(assuming you have or can get possession of source to it), or by
#define-ing over the I/O routines and testing for redirection yourself.

>Failing that, can I temporarily (only during program execution)
>install a device driver which is part of the program to handle DOS's
>stdout/stderr (I believe they're one in the same for DOS) streams?

Standard output and error are two separate file handles (which are,
incidentally, "always open"), but by default they both point to the
CON device.  They can be redirected independently.

As I mentioned above, temporarily installing drivers is not my idea
of a good time.  But device drivers can be very small, especially if
all they contain is a bunch of far pointers to code in your .EXE
which implements them.

Has anyone here ever linked in a driver themselves?  Just how *is* it
done, anyway?

>Failing that, can I suppose I can clobber printf with my own routine
>which uses vsprintf.  Similarly with putc.

By using this technique, you get portability to boot.  And if you
can get some compiler vendor to add it to their library, it just might
appear in the next standard :-).

Eric Hughes
hughes@math.berkeley.edu   ucbvax!math!hughes