byu@csri.toronto.edu (Benjamin Yu) (08/02/88)
I was trying to putc a byte (hex 1A) to stdprn using Microsoft C V4.0. Since hex 1A is ctrl-Z which stands for end-of-file, the byte is never sent. Now is this a bug or a feature in handling eof?? In either case, can anyone advise me how I can send hex 1A to stdprn?? Benjamin Yu University of Toronto CSNET : byu@csri.toronto.edu Department of Computer Science UUCP : uunet!csri.utoronto.ca!byu Toronto, Ontario Canada M5S 1A4 BITNET : byu@csri.utoronto (o) (416) 978 - 4299 (h) (416) 470 - 8206
dhesi@bsu-cs.UUCP (Rahul Dhesi) (08/04/88)
In article <8808021504.AA05128@wilson.csri.toronto.edu> byu@csri.toronto.edu (Benjamin Yu) writes: >I was trying to putc a byte (hex 1A) to stdprn using Microsoft C V4.0. >Since hex 1A is ctrl-Z which stands for end-of-file, the byte is never >sent. This is really a bug in MS-DOS, though it was probably intended as a feature. When sending output to a character-oriented device, a control Z is used to indicate end-of-file too. This isn't necessary, but it happens. So the PRN printer device driver, when it sees control-Z, assumes no more data will arrive and freezes up, refusing to accept any more characters. To see this philosphy in action, try giving MS-DOS this command: echo ^Z If all goes normally, you will see the response "Insufficient disk space". What really happened was that when the console driver saw the control Z, it assumed end-of-file had arrived, and so refused to accept any data. COMMAND.COM realized that the console was refusing to print, and assumed that it couldn't send stuff because of a full disk. A hypothetical solution is to put the printer device into raw mode. You have to write a program to do this. I don't know if it will work for you. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
kneller@cgl.ucsf.edu (Don Kneller) (08/05/88)
In article <8808021504.AA05128@wilson.csri.toronto.edu> byu@csri.toronto.edu (Benjamin Yu) writes: >In either case, can anyone advise me how I can send hex 1A to stdprn?? > You will have to place stdprn into binary mode first. In principle, this code fragment should do it but I haven't attempted it: #include <stdio.h> #include <fcntl.h> stdprn_binary() { setmode(stdprn, O_BINARY); } ----- Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller INTERNET: kneller@cgl.ucsf.edu BITNET: kneller@ucsfcgl.BITNET
creps@silver.bacs.indiana.edu (Steve Creps) (08/05/88)
In article <8808021504.AA05128@wilson.csri.toronto.edu> byu@csri.toronto.edu (Benjamin Yu) writes: >In either case, can anyone advise me how I can send hex 1A to stdprn?? You might try making a call to setmode() on stdprn to put in into binary mode. - - - - - - - - - - Steve Creps, Indiana University, Bloomington, home of the "Hoosiers" creps@silver.bacs.indiana.edu (192.12.206.2) {inuxc,rutgers,pyramid,pur-ee}!iuvax!silver!creps creps@iubacs.bitnet (forwarded)
cramer@optilink.UUCP (Clayton Cramer) (08/05/88)
In article <3559@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > In article <8808021504.AA05128@wilson.csri.toronto.edu> byu@csri.toronto.edu > (Benjamin Yu) writes: > >I was trying to putc a byte (hex 1A) to stdprn using Microsoft C V4.0. > >Since hex 1A is ctrl-Z which stands for end-of-file, the byte is never > >sent. > > When sending output to a character-oriented device, a control Z is used > to indicate end-of-file too. This isn't necessary, but it happens. So > the PRN printer device driver, when it sees control-Z, assumes no more > data will arrive and freezes up, refusing to accept any more > characters. > > A hypothetical solution is to put the printer device into raw mode. > You have to write a program to do this. I don't know if it will work > for you. > -- > Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi Use the setmode(fileno(stdprn), O_BINARY) call to put stdprn into raw mode from C. Clayton E. Cramer [I hate the 50% rule]
littauer@amdahl.uts.amdahl.com (Tom Littauer) (08/06/88)
In article <11074@cgl.ucsf.EDU> kneller@socrates.ucsf.edu.UUCP (Don Kneller) writes: >In article <8808021504.AA05128@wilson.csri.toronto.edu> byu@csri.toronto.edu (Benjamin Yu) writes: >>In either case, can anyone advise me how I can send hex 1A to stdprn?? >> >You will have to place stdprn into binary mode first. The variation I was trying to make work once was sending print output to stdout, then redirecting it to either a file or PRN: as desired. Yes, I set the mode of stdout to binary, and it worked fine TO DISK ONLY. When I redirected to the printer, the 0x1a got dropped, causing much confusion. Even copying the (correct) disk file to the printer failed the same way. I was sure my printer was broken, and put much pressure on the vendor. They came through for me (thank you, Fujitsu America) and discovered that the printer driver was eating the 0x1a. I fell back on using the BIOS call to send data to the printer. That works. Good luck on anything else. -- UUCP: littauer@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ames,uunet}!amdahl!littauer DDD: (408) 737-5056 USPS: Amdahl Corp. M/S 337, 1250 E. Arques Av, Sunnyvale, CA 94086 I'll tell you when I'm giving you the party line. The rest of the time it's my very own ravings (accept no substitutes).
grosen@amadeus.ucsb.edu (Mark D. Grosen) (08/07/88)
> Problems printing binary files . . . .
I went through the same problems with trying to print binary files with
MSC. Somebody mentioned earlier about using setmode(file, O_BINARY).
Another method is to set the global variable _fmode to binary so that all
files are opened in binary mode.
If you have a disk file (binary, contains 0x1a) that you want to print,
generic MSDOS print won't work. Using a plain copy command won't work
UNLESS you use the binary option, as in
C:> copy /b print.fil lpt1:
(I hope that option is right; see your DOS manual.) I guess DOS checks
the destination and if it's a device (printer) interprets the file
differently.
Mark
Mark D. Grosen ARPA: grosen@amadeus.ucsb.edu
Signal Processing Lab / Communications Research Lab
ECE Dept.
University of California
Santa Barbara, CA 93106