markz@microsoft.UUCP (Mark Zbikowski) (06/12/84)
Here are some answers to a recent question and comment: "How can I open the console in such a manner that it is not redirected and no apparent buffering?" Just like *NIX, you may open a device and place the channel into raw mode. After this point, any I/O you do will be done directly to the device with no special character processing at all. This means no ^S/^Q, printer echoing or ^C checking (remember break-on still checks at system-call entry). The conversion to raw mode is imperfectly described in the IBM manual under the IOCTL system call. In particular, you must set the "ISBIN" bit. "Use handle 2 as it is immune from redirection" Not quite true. More correctly: "At the present time, there is no way to redirect stderr from the command line". In a manner much like *NIX, MSDOS allows a program to control the environment of its child. For handles, the child inherits the parents set of open files. If the parent closes handle 2 and reopens it as file foo, then the child will get file foo.
markz@microsoft.UUCP (Mark Zbikowski) (06/27/84)
"... What markz@microsoft is saying is "Sorry folks, there is a class of calls that do not properly (or fully) support redirection. You should not use these calls."..." I will freely admit to that. It is *extremely* difficult to add functionality to an existing operating system, maintain compatability and give all existing programs (no matter how poorly they are written) the benefits of these new features. Microsoft made the best choices we could. I can apologize for the documentation only so far. Programmers write it and tech writers rewrite it. Unfortunately, much got lost in the translation. "... distinction between "CPM-style" and "new" calls..." I am sorry for the confusion. I believe that most of the readers of this news group were ex-CPMers and I was presuming on their knowledge. The CPM calls were the calls that were present in MSDOS and DOS 1.*. The new calls are the ones added for 2.0. "...Why is it necessary to duplicate the original stdin and then close it? No reason. The programmer just made the decision that he'd mix some old and new calls (he uses read-single-byte-from-stdin and read-handle). He uses the read-handle to read the redirected input and uses the read-single-byte-from- stdin to read a single unbuffered byte from the console. Note that he duplicates stderr (handle 2) to be stdin. This relies on the assumption that stderr would not get redirected. He may have just placed handle 2 into raw mode (using the IOCTL system call to get and set device information) and then used the read-handle calls instead. "... The new stderr handle is not saved and is not used...." The program relies on the operating system to return the lowest available handle on a dup call or on an open call. This is a common practice on *NIX. He may use the force-duplication-on-handle system call to explicitly duplicate it too. "... Was this used to support control-S, control-Q, and control-BREAK?..." As per the above comments, it was just a choice that the programmer made. "... Do the "new calls" support them?..." Yes, but only when the handle is in raw mode. The distinction between raw and cooked mode is like *NIX but not identical to it. There is no distinction between raw and cooked for a file; the following is for character devices only. A read in cooked mode will read an entire line of text. It allows you to use the function keys and ^P/print-screen key. If you issue one-byte reads, the OS will read an entire line on the first one and then pass back the bytes one-at-a-time for the subsequent reads until the end-of-line is hit. Due to CPM-compatability, all lines are terminated with CR-LF (sorry, *NIX hackers). Despite the fact that you hit *only* an ENTER key at the end-of-line, your program will receive BOTH a CR and a LF. The input will stop at the first ^Z found and return an EOF indication. Note that all charactes are echoed. A write in cooked mode will look for ^S, ^P/print-screen and ^C/control-break. It will stop at the first ^Z. Raw mode is a different story. A one byte read will return *immediately* when the input byte is seen. Note that I said byte. Function keys transmit two bytes (a NUL followed by a scan-code). ^S, ^C, etc ae passed through directly. If you read n bytes, the OS will sit there and wait until you've entered n bytes. No echoing is performed. A write in raw mode is lightning fast; no check for the special characters is done. A single packet is sent to the device driver to output the entire chunk. It is distinctly unfriendly for someone to write 64K in this mode to the screen... "... Or was it used just to get tab expansion?..." He was using the read-single-byte call only for the raw-ness of it. The single-byte I/O call is funny; it is a raw input that echos. "... I have looked at the source for more.c and can find no duplication and closing of stdin...." Again, the programmer decided to shortcut the use of IOCTL to get his unbuffered I/O. "... my C compiler is not using "new calls"..." Actually, I believe that your runtime is not using the new calls, especially with regards to stdin/stdout. You may want to wander through the executable with a debugger to see what's happening.