Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!iuvax!bsu-cs!dhesi From: dhesi@bsu-cs.UUCP (Rahul Dhesi) Newsgroups: comp.sys.ibm.pc Subject: Re: Printer blues Summary: bug or feature? Keywords: printers binary Message-ID: <4907@bsu-cs.UUCP> Date: 30 Nov 88 20:02:38 GMT References: <17693@santra.UUCP> Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi) Organization: CS Dept, Ball St U, Muncie, Indiana Lines: 38 In article <17693@santra.UUCP> makela_otto_@jylk.jyu.fi writes: >After lots of debugging and guesswork, I came to the conclusion that the >standard MS-DOS write interface DOES NOT ALLOW ^Z CHARACTERS TO GO OUT TO >THE PRINTER. The bug is in the printer driver, not in the write system call itself. I think this was originally intended to be a feature, but it turned out to be a bug. When you say "copy file PRN" you are really saying "copy everything in this file to my printer". But without realizing it, you are also saying "copy everything in this file that's my data to the printer, but don't copy any junk beyond the end of my data." Because of its CP/M heritage, MS-DOS's old convention was that control Z in a text file marked the end of data within the file. Many programs, using the old FCB-based system calls, created files that contained a control-Z followed by junk. Some word processors even use the junk beyond the control-Z to store their own configuration information. This is more easy to understand if you call control-Z the "end of user data" mark rather than the "end of file" mark. [This paragraph is pure speculation.] To avoid your seeing this junk when you sent such a file to the printer, the good people at Microsoft decided that the printer would simple refuse to accept anything once it saw a control-Z. For the same reason, when you do "type file" the console driver stops accepting data when it sees a control Z, sparing you seeing much junk on the screen. (Naturally, command.com has to play some tricks to make sure that output from the next command given will still show up.) What you can still do is use the IOCTL system call in MS-DOS to tell the printer to go into binary mode and accept all characters. (This is *not* the same as a file opened in binary mode from a C program.) What MS-DOS badly needs is an "stty.exe" program that will allow devices to be configured. -- Rahul Dhesi UUCP:!{iuvax,pur-ee}!bsu-cs!dhesi