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 = '}