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