steve@lpi3230.UUCP (Steve Burbeck) (07/05/86)
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.
Steve Burbeck
Linus Pauling Institute
(415) 327-4064chapman@pavepaws.berkeley.edu (Brent Chapman) (07/06/86)
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!)
kneller@ucsfcgl.UUCP (Don Kneller%Langridge) (07/07/86)
In article <805@ucbcad.BERKELEY.EDU> chapman@pavepaws.UUCP (Brent Chapman) writes: >In article <165@lpi3230.UUCP> steve@lpi3230.UUCP (Steve Burbeck) writes: >>MICROSOFT C PROBLEM? >> >> [complaint about opening a binary stream to a printer closing when a ^Z >> is written out] > >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). ... > >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.) > (hi Brent) Definitely not true. In binary mode, when writing to a *file*, ^Z is just another 8 bits. Same with input from a file. Unfortunately, I don't have a solution to the problem of getting the ^Z to the device. I think sending ^Z to the screen has the same effect (but I'm not sure) so the problem may be a general device driver problem. Perhaps you have to put the device into raw mode. -- Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller ARPA: kneller@ucsf-cgl.ARPA BITNET: kneller@ucsfcgl.BITNET
john@quad1.UUCP (07/08/86)
> 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. > > I believe the ^Z is ignored when reading files in binary mode. John Crane