josephc@tybalt.caltech.edu (Joseph I. Chiu) (05/04/90)
Help! I have a graphical application that sends data to the printer. The problem is that there are character code 0x1A in the stream of data going to the PRN. Unfortunately, it seems MS-DOS loves to intercept the 0x1A (which is a control-Z, otherwise known as the end-of-file code) and refuse to send any more data until it encounters some other character (like a carriage return or a line) that it likes. In the meanwhile, it drops out a few bytes of data in between. Does anyone have a solution to this that does NOT require the use of bios printing services? In particular, the program is in C, and I'd like to keep the portability as much as possible in the source. If I have to run a little patch program to modify MS-DOS itself, though, I won't mind. -Joseph ------------------------------------------------------------------------------- I wish I was somewhere else, walking down a strange new street... Hearing words that I have never heard before, from a girl I've yet to meet... - It Might As Well Be Spring (Rodgers & Hammerstein II) ------------------------------------------------------------------------------- JosephC @ Romeo.Caltech.Edu My opinions, all mine, and you can't have them! -------------------------------------------------------------------------------
josephc@tybalt.caltech.edu (Joseph I. Chiu) (05/05/90)
This is a preliminary followup to my article asking for help with the way MS-DOS intercepts a EOF going to the printer. First, thanks to those of you who have started sending suggestions. A few people mentioned that the FILE stream had to be opened as a binary stream. That is, in fact, the way I have been running it. It works almost perfectly EXCEPT for the fact that it intercepts a EOF character. By the way, most C implementations open the stdprn as a binary stream, so that wasn't it. ( By the way, it is almost always a good idea to freopen the three std-streams. That way, you can redirect your programs' output to a file as an added bonus!) A few more people mentioned COPYing the file to the printer. Most were quick to point out that you had to use COPY /B FILE PRN. THIS WORKS. (I was thinking about COPY, but I forgot all about the /B, so I had gibberish there, too). Finally, someone mentioned using the ioctl function. Hmmm.. Seems to me, from what information I have currently, it would work. I'll try it and give you guys a holler later about this... The gist of it is that you have to tell DOS to stop treating the PRN device in "cooked mode". Thanks guys. I LOVE the net... You are wonderful. (Try getting this fast support/service with Borland or Microsoft... Ugh.) -Joseph ------------------------------------------------------------------------------- I wish I was somewhere else, walking down a strange new street... Hearing words that I have never heard before, from a girl I've yet to meet... - It Might As Well Be Spring (Rodgers & Hammerstein II) ------------------------------------------------------------------------------- JosephC @ Romeo.Caltech.Edu My opinions, all mine, and you can't have them! -------------------------------------------------------------------------------
pnl@hpfinote.HP.COM (Peter Lim) (05/08/90)
> I have a graphical application that sends data to the printer. The problem > is that there are character code 0x1A in the stream of data going to the > PRN. Unfortunately, it seems MS-DOS loves to intercept the 0x1A (which > is a control-Z, otherwise known as the end-of-file code) and refuse to send > any more data until it encounters some other character (like a carriage > return or a line) that it likes. In the meanwhile, it drops out a few bytes > of data in between. > > Does anyone have a solution to this that does NOT require the use of bios > printing services? In particular, the program is in C, and I'd like to keep > the portability as much as possible in the source. If I have to run a > little patch program to modify MS-DOS itself, though, I won't mind. > What you mean is not very clear. Does you C program write directly to the printer ? Or does it produce a file which you later dump to the printer from DOS ? Assuming you have access to the source code, when you open the device for write, use mode "wb" instead of just "w" (as you would under UNIX). This means binary mode and usually means don't add a carriage-return when you send a line-feed. I don't know if it do something to the Ctrl-Z stuff. But is definitely needed. Then, if you're copying the output file to the printer from DOS, try using COPY FILE PRN: /B for binary mode copy and so Ctrl-Z will not act as EOF mark. In any case, do not use the PRINT command from DOS which only handles text file. Hope that helps. Regards, ## Life is fast enough as it is ........ Peter Lim. ## .... DON'T PUSH IT !! >>>-------, ########################################### : E-mail: plim@hpsgwg.HP.COM Snail-mail: Hewlett Packard Singapore, : Tel: (065)-279-2289 (ICDS, ICS) | Telnet: 520-2289 1150 Depot Road, __\@/__ ... also at: pnl@hpfipnl.HP.COM Singapore 0410. SPLAT !