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