🚀 go-pugleaf

In article <165@lpi3230.UUCP> steve@lpi3230.UUCP (Steve Burbeck) writes:
>MICROSOFT C PROBLEM?
>
>     The task is to output a binary bit map to a printer (in this case, an HP
>ThinkJet, but the same problem occurs with an IBM Proprinter).  The seemingly
>reasonable way to do it is with the following kind of open and write (using
>Microsoft C version 3.00, an IBM PC/AT, and DOS 3.1):
>
>	handle = open(name,mode|O_BINARY);
>	i = write(handle, buf, i);
>
>The printer is opened by name 'PRN'.  The problem is that the write terminates
>whenever it encounters a bit pattern byte with a value of hex 1A (decimal 26
>which is the DOS EOF char).  If the same bitmap data is written to a disk file,
>then copied to the PRN device using DOS COPY /B, the EOF data bytes cause no
>problem!
>
>Does anyone have a clue?
>
>By the way, the program must not be required to know that it is writing to
>a printer, the open must be general purpose.  So a solution that works only
>for the printer, but fails for writing to a disk file is not useful.

If I remember right (in other words, my MSC manuals are at work and I'm
at home), the write() call terminates on a 0x1A (^Z).  Since you can't
(in this case, because it is binary data) just remove the ^Z like you
could if you were concattenating files, you'll need to use another file
handling call.  I don't think that ignoring/using ^Z can be toggled
for the write() call.

MSC's designation of "binary" is somewhat misleading.  All that "binary"
really means is that CR/LF pairs are not converted to simple newlines on
input, and vice versa on output.  "Binary" mode doesn't affect the meaning
of the DOS EOF marker.  The read() command, I believe, also terminates on
a ^Z, regardless of whether or not it's at physical EOF (but, since I don't
have my manuals, I'm not CERTAIN of this...  Look it up.)

I agree that this is stupid; there is no need for an EOF marker in current
versions of DOS.  The EOF marker is a holdover from earlier versions.  There
are certain programs that choke if it's there, and others that choke if it's
not.


Brent

--

Brent Chapman
chapman@pavepaws.berkeley.edu
ucbvax!pavepaws!chapman

TANSTAAFL!  (There Ain't No Such Thing As A Free Lunch!)