woodside@ttidca.TTI.COM (George Woodside) (03/05/90)
When a binary file is opened under MSC (5.1), and the file name is a
device (AUX, CON, PRN, NUL), the binary mode is not completely
transparent. It does stop altering line feeds to carriage return/line
feeds, but it still stops and (apparently) closes the device when the
data stream contains the EOF character 0x1a. The fwrite calls write,
where the library reference manual states "When writing to a device,
write treats a CTRL+Z character in the buffer as an output terminator."
In reality, when a binary data stream (a graphic image) to a printer
contains an 0x1a character, the output is truncated, and eventually the
subsequent write calls will return a file write error.
Is there any method, save byte-at-a-time INT output, to write a binary data
stream transparently to a device?
--
* George R. Woodside - Citicorp/TTI - Santa Monica, CA *
* Path: woodside@ttidca *
* or: ..!{philabs|csun|psivax}!ttidca!woodside *cb@sequoia.UUCP (Christopher D. Brown) (03/06/90)
In article <10521@ttidca.TTI.COM> woodside@ttidca.tti.com (George Woodside) writes: >When a binary file is opened under MSC (5.1), and the file name is a [edited} >In reality, when a binary data stream (a graphic image) to a printer >contains an 0x1a character, the output is truncated, and eventually the >subsequent write calls will return a file write error. > [edited} After opening the file you need to use the DOS IOCTL Get Device Information function to check for a character device and the DOS IOCTL Set Device Information to set the character device to raw mode. SetRawMode( int Handle ) { union REGS Regs; Regs.x.ax = 0x4400; Regs.x.bx = Handle; intdos( &Regs, &Regs ); if ( !Regs.cflag ) { if ( Regs.x.dx & 0x0080 ) { Regs.x.ax = 0x4401; Regs.x.bx = Handle; Regs.x.dx &= 0x00AF; intdos( &Regs, &Regs ); } } } ----- Christopher D. Brown Digital: {uunet|texbell|cs.utexas.edu}!execu!cb Analog: (512) 327-7070 Physical: Execucom, 108 Wild Basin Road, Two Wild Basin, Austin, TX 78764 -- Christopher D. Brown Digital: {uunet|texbell|cs.utexas.edu}!execu!cb Analog: (512) 327-7070 Physical: Execucom, 108 Wild Basin Road, Two Wild Basin, Austin, TX 78764
dixon@ra.crd.ge.com (walt dixon) (03/06/90)
If one opens a device at the DOS level (using a handle), and then
does an IOCTL to place the device in raw mode, all output (including
0x1a) goes directly to the device. Raw mode also has a definte
performance advantage over text mode. DOS sends text mode writes
to the driver one character at a time but sends the entire request
with one driver call for raw mode.
Walt Dixon {arpa: dixon@crd.ge.com }
{us mail: ge crd }
{ po box 8 }
{ schenectady, ny 12301 }
{phone: 518-387-5798 }
Walt Dixon dixon@crd.ge.comkdq@demott.COM (Kevin D. Quitt) (03/07/90)
I ran into precisely the same problem when trying to output graphics
data to an Epson printer. What I ended up doing was writing to a file,
then using the system() call to invoke copy with the /b parameter:
result = system( "copy /b filename.ext prn >nul" );
While the /b should only be required for DOS 2.0 and earlier files,
it's required to bypass the ^Z. Yet another example of microcomputer
brain damage by the authors of DOS.
kdq
--
Kevin D. Quitt Manager, Software Development
DeMott Electronics Co. VOICE (818) 988-4975
14707 Keswick St. FAX (818) 997-1190
Van Nuys, CA 91405-1266 MODEM (818) 997-4496 Telebit PEP last
34 12 N 118 27 W srhqla!demott!kdq kdq@demott.com