Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!nike!ucbcad!ucbvax!ucsfcgl!kneller
From: kneller@ucsfcgl.UUCP (Don Kneller%Langridge)
Newsgroups: net.micro.pc
Subject: Re: printing bitmaps to ThinkJet from within Microsoft C program
Message-ID: <9905@cgl.ucsf.edu.ucsfcgl.UUCP>
Date: Sun, 6-Jul-86 18:39:33 EDT
Article-I.D.: cgl.9905
Posted: Sun Jul  6 18:39:33 1986
Date-Received: Mon, 7-Jul-86 02:25:20 EDT
Reply-To: kneller@cgl.ucsf.edu.UUCP (Don Kneller%Langridge)
Organization: Computer Graphics Laboratory, UCSF
Lines: 31

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