home *** CD-ROM | disk | FTP | other *** search
/ The C Users' Group Library 1994 August / wc-cdrom-cusersgrouplibrary-1994-08.iso / vol_100 / 171_01 / dos_err.txt < prev    next >
Text File  |  1983-10-30  |  3KB  |  61 lines
  1.         DOS 2.0 HAS PROBLEMS WITH REDIRECTION OF I/O
  2.  
  3.      There  are  problems  in  DOS  2.0 with the redirection of I/O and
  4.  piping for programs that use the original  DOS  1.1  INT  21  function
  5.  calls    for  input.   This  problem  is  readily apparent to users of C
  6.  language packages such as Computer  Innovation  C-86,    Lattice  C,  or
  7.  Microsoft  C  (you'd  think  they  would  get it right!).  One problem
  8.  is that all output to the screen is redirected,  even    keyboard  echo.
  9.  Correct  operation  would  redirect  all program output for the screen
  10.  (stdout) to the specified >file, but the echo of keyboard input  would
  11.  still    be  sent  to  the  screen.  Instead, both the keyboard echo and
  12.  the program output are sent to the redirected    >file.     Thus,    if  you
  13.  run  programs    such as the CAT.C (K&R,page 154) example that Microsoft
  14.  distributes with their C; or COPYIO.C (K&R,page 15)  with  the  output
  15.  redirected to a file, you will get the following results:
  16.  
  17.       1.   Under  DOS  1.1, keyboard input is echoed to the screen
  18.       as you type and each line  appears  in  the  >file  once    as
  19.       expected.
  20.  
  21.       2.   Under  DOS  2.0,  keyboard  input  is not echoed to the
  22.       screen, but each line appears in the >file twice!
  23.  
  24.      This situation is handled correctly in DOS  2.0  if  the  new  INT
  25.  21  function call 3F is used.    This can be demonstrated by redirecting
  26.  output for the DOS 2.0 function MORE - it works as desired.
  27.  
  28.      The redirecting of input to these programs doesn't  work  properly
  29.  either.   If  the  file  has  not been edited with debug to end with a
  30.  control-Z, the program will hang up at the end  of  the  <input  file.
  31.  You  must reboot the system to continue!  Also, if you pipe the output
  32.  of the first program into a second  program,  the  final  output  will
  33.  contain  each    line  four times, doubled spaced after the second line!
  34.  These problems do not occur for programs that    use  the  new  DOS  2.0
  35.  calls for I/O, such as SORT and MORE.
  36.  
  37.      The  question  now  is  how  do  you fixup C programs to run under
  38.  DOS 2.0 and not redirect keyboard echo to the stdout file?  The easiest
  39.  way for C compilers that include their  own  redirection  code  is  to
  40.  change their redirection symbols from <, >, and >> to something else. Then
  41.  DOS  2.0  won't  do  the redirection, so the C code will be able to do
  42.  it correctly.    With the Microsoft C compiler, this is easily accomplished
  43.  by modifying three lines of code in _MAIN.C.    A  good  choice  is  to
  44.  modify  _MAIN.C  so  that  it    redirects  on the symbols {, }, and }}.
  45.  The only restriction is that these symbols then  should  not  be  used
  46.  in  filenames.   With these changes, the user can choose to let either
  47.  DOS  <, >, >>    or C  {, },  }}   do  the  redirecting.   The  modified
  48.  version  of  _MAIN.C  is compiled to obtain a new _MAIN.OBJ, which can
  49.  either be put into the library MC.LIB to replace  the    original  _MAIN
  50.  by  using  the  LIB.EXE  utility,  i.e.     LIB   MC.LIB  -_MAIN+_MAIN
  51.  or it can be kept separate.  If kept  separate,  remember  to    include
  52.  it  in  the  list  of    .OBJ  files  specified    in  the LINK call, i.e.
  53.  LINK c _main myprogram.
  54.  
  55.      The three lines to change in Microsoft C's  _MAIN are:
  56.       case '{':
  57.       case '}':
  58.       if (*line == '}')
  59.  
  60.      Kludgy, yes, but it works better than before!!     WHR    9-26-83
  61.