63 lines
3.4 KiB
Plaintext
63 lines
3.4 KiB
Plaintext
|
||
DOS 2.0 HAS PROBLEMS WITH REDIRECTION OF I/O
|
||
|
||
There are problems in DOS 2.0 with the redirection of I/O and
|
||
piping for programs that use the original DOS 1.1 INT 21 function
|
||
calls for input. This problem is readily apparent to users of C
|
||
language packages such as Computer Innovation C-86, Lattice C, or
|
||
Microsoft C (you'd think they would get it right!). One problem
|
||
is that all output to the screen is redirected, even keyboard echo.
|
||
Correct operation would redirect all program output for the screen
|
||
(stdout) to the specified >file, but the echo of keyboard input would
|
||
still be sent to the screen. Instead, both the keyboard echo and
|
||
the program output are sent to the redirected >file. Thus, if you
|
||
run programs such as the CAT.C (K&R,page 154) example that Microsoft
|
||
distributes with their C; or COPYIO.C (K&R,page 15) with the output
|
||
redirected to a file, you will get the following results:
|
||
|
||
1. Under DOS 1.1, keyboard input is echoed to the screen
|
||
as you type and each line appears in the >file once as
|
||
expected.
|
||
|
||
2. Under DOS 2.0, keyboard input is not echoed to the
|
||
screen, but each line appears in the >file twice!
|
||
|
||
This situation is handled correctly in DOS 2.0 if the new INT
|
||
21 function call 3F is used. This can be demonstrated by redirecting
|
||
output for the DOS 2.0 function MORE - it works as desired.
|
||
|
||
The redirecting of input to these programs doesn't work properly
|
||
either. If the file has not been edited with debug to end with a
|
||
control-Z, the program will hang up at the end of the <input file.
|
||
You must reboot the system to continue! Also, if you pipe the output
|
||
of the first program into a second program, the final output will
|
||
contain each line four times, doubled spaced after the second line!
|
||
These problems do not occur for programs that use the new DOS 2.0
|
||
calls for I/O, such as SORT and MORE.
|
||
|
||
The question now is how do you fixup C programs to run under
|
||
DOS 2.0 and not redirect keyboard echo to the stdout file? The easiest
|
||
way for C compilers that include their own redirection code is to
|
||
change their redirection symbols from <, >, and >> to something else. Then
|
||
DOS 2.0 won't do the redirection, so the C code will be able to do
|
||
it correctly. With the Microsoft C compiler, this is easily accomplished
|
||
by modifying three lines of code in _MAIN.C. A good choice is to
|
||
modify _MAIN.C so that it redirects on the symbols {, }, and }}.
|
||
The only restriction is that these symbols then should not be used
|
||
in filenames. With these changes, the user can choose to let either
|
||
DOS <, >, >> or C {, }, }} do the redirecting. The modified
|
||
version of _MAIN.C is compiled to obtain a new _MAIN.OBJ, which can
|
||
either be put into the library MC.LIB to replace the original _MAIN
|
||
by using the LIB.EXE utility, i.e. LIB MC.LIB -_MAIN+_MAIN
|
||
or it can be kept separate. If kept separate, remember to include
|
||
it in the list of .OBJ files specified in the LINK call, i.e.
|
||
LINK c _main myprogram.
|
||
|
||
The three lines to change in Microsoft C's _MAIN are:
|
||
case '{':
|
||
case '}':
|
||
if (*line == '}')
|
||
|
||
Kludgy, yes, but it works better than before!! WHR 9-26-83
|
||
END OF TRANSFER - PRESS ENTER TO RETURN TO MENU
|
||
= '} |