dag@tellab2.UUCP (Donald Graft) (06/13/84)
Some recent net discussion has pointed out a problem with I/O redirection
in MS-DOS 2.x. The problem stated was that one could not force I/O to
the console when redirection is in effect. I have solved this problem
by making direct calls to the ROM BIOS. Granted, this is an ugly
solution that will not port to many machines, but it works on IBM PCs
and clones.
This problem, however, is only the tip of the iceberg where I/O redirection
is concerned. First, no one can fail to notice the haphazard way that the
function calls support redirection (this one doesn't, this one does, this
one does BUT..., etc.). Second, the mechanism is not totally transparent;
e.g., for output redirection, tabs are expanded to eight spaces (if you
want to keep your tabs, or expand them differently, tough luck). Third,
the input redirection mechanism will not reliably detect end of file using
all function calls that supposedly support redirection. The DOS manual
even contains a warning to this effect; if the program tries to read more
data than is there, the program will hang (or words to that effect). In
other words, forget end of file. It seems to me that the I/O redirection
feature of DOS 2.x was crammed in to make DOS 2.x seem "UNIX-like". It is
OK for just taking a known set of commands from a file for use by a program,
but for filter applications, it is useless.
Despite these problems, and I'm sure there are others waiting to be found,
the MORE filter seems to perform acceptably with its input redirection. I
therefore disassembled the program to see how they were doing it. My
disassembly is not on hand but I can remember that several pieces of
magic were included, e.g., creating a file handle copy of stdin, closing
the original stdin, and using the duplicate with a low-level read operation.
I also tried duplicating this with a program written in Desmet C. It
would not operate correctly, so I assume some magic got interfered with
by the compiler. But, why doesn't IBM or MicroSoft TELL US what magic we
have to play to get the stupid redirection to even approach working???
Something about hanging out dirty laundry.
After six weeks of trying to solve all these problems, I gave up. I now
provide my own redirection mechanism using the { and } characters (I
don't want to patch out the < and > because it's horrid and customers
don't like to be told they have to patch their operating system to make
a product work).
If anybody has solved any of these problems, I would love to hear from
them.
...ihnp4!tellab1!tellab2!dag Donald Graft