markz@microsoft.UUCP (06/16/84)
"... First, no one can fail to notice the haphazard way that the function calls support redirection (this one doesn't, this one does, this one does BUT..., etc.)..." I believe that all I/O system calls do support redirection without "haphazardness". Calls that used to be unnamed I/O to the screen now direct their output to stdout; those that receive I/O from the keyboard derive their input from stdin. Similarly, unnamed I/O to the aux and printer perform their output via stdaux and stdprn. "... expanded tabs..." Tabs are *only* expanded for the CPM-compatible system calls. Handle-based calls output tabs. "... Third, the input redirection mechanism will not reliably detect end of file using all function calls that supposedly support redirection..." I believe that all system calls that have the notion of end-of-file do correctly return end-of-file. Old CPM-style calls do NOT have a notion of end of file and, thus, were made to read up to eof and hang. There is no *correct* behavior for these calls *except* to hang. Many ideas have been proposed: Return ^Z at eof. Not a lot of programs understand that ^Z is EOF. Return NUL at eof. What about the IBM function keys? Again, programs will fail if they interpret the IBM function keys. Return input to the 'console'. Ick. Giving the ability to redirect input to these old programs was a pretty good feature. If the user makes a mistake by placing less input into his file than his program requires, at least we give him the opportunity to ^C out of things. If ISV's will make use of the new handle-based system calls, they will find that I/O is handled in a uniform manner. "... I also tried duplicating this with a program written in Desmet C. It would not operate correctly..." I believe that there are several compilers on the market that restrict themselves to the 1.1 system calls and do NOT make any attempt to use the new 2.0 calls. Typically, this is merely a runtime issue that can be overriden easily by replacing the offending routines in the library. I was easily able to replace the 1.1 Lattice C routines with my own that gave me 2.0 capabilities. "... several pieces of magic were included, e.g., creating a file handle copy of stdin, closing the original stdin, and using the duplicate with a low-level read operation..." Magic? That sounds just like MORE on *NIX to me. That is exactly the correct behavior. "... why doesn't IBM or MicroSoft TELL US what magic we have to play to get the stupid redirection to even approach working???..." All of the system calls used by MORE are documented in the IBM PC manual.