🚀 go-pugleaf

I have written a DVI to HP LaserJet+ Driver that runs under both Unix
and MS/PC-DOS.  Unfortunately, I have discovered a problem either in the
Aztec C Run-time support, (which they deny), or a problem with MS-DOS,
(a misunderstanding, no doubt).  I am running MS-DOS V3.1 and am
putc()ing characters to a stream that was successfully opened via
fopen() for "w" access to "COM1".  I check the returned pointer for NULL
and guaranteed fopen()s success.  However, after writing BUFSIZ
characters, putc() returns EOF.  I traced the run-time code and found
that a DOS write handle was returning less bytes than were written.  The
Manx code gave up the ghost and died.  I rewrote the routine to loop
through write() calls until the entire buffer had been written.  When I
compiled and ran the code, MS-DOS continually and repeatedly refused to
accept any more data to the fopen()ed handle. 

Next, instead of directing output to COM1 I started sending the data to
the disk file "laserjet.dat" and was pleased to find that the data was
indeed there and correct.  I then copied the file to COM1 via the
command:

	COPY LASERJET.DAT COM1

and was disturbed to find that the file did not print on the LaserJet. 
After reading the DOS manual I discovered that the /B option for COPY
would probably correct the problem.  I used it and it did! OK, the
question is, "WHAT MS-DOS FUNCTION CALL DID COPY MAKE TO CAUSE THE FILE
TO PRINT?" It sounds like the handle must be placed in raw mode, or
something synonymous.  Unfortunately, I do not know how to do this, and
the programmer's manual for MS-DOS is not too helpful.  Any help would
be appreciated.  Writing to a temporary file and then system()ing COPY
is not an acceptable solution.  Many thanks in advance.

	Dave Richards at Hewlett-Packard Labs (drichard@hplabs)