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