Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!seismo!rochester!ritcv!rocksvax!rocksanne!sunybcs!cald80!bob From: bob@cald80.UUCP Newsgroups: comp.sys.ibm.pc Subject: Re: Need help with MS-DOS 3.1 and COM1 device Message-ID: <784@cald80.UUCP> Date: Thu, 5-Feb-87 12:38:49 EST Article-I.D.: cald80.784 Posted: Thu Feb 5 12:38:49 1987 Date-Received: Sun, 8-Feb-87 05:56:17 EST References: <3281@hplabs.hplabs.UUCP> Reply-To: bob@cald80.UUCP (bob) Organization: Calspan Advanced Technology Center Lines: 34 In article <3281@hplabs.hplabs.UUCP> drichard@hplabs.UUCP (Dave Richards) writes: > >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. > >...much deleted for Pnews > Dave Richards at Hewlett-Packard Labs (drichard@hplabs) I have found that fopen()ing a file causes the system to assume that you are going to send text to it. It usually turns on ^Z mapping to end of file. It also does \n to \r\n mapping. Needless to say, you can't pump binary to it. In the Desmet C compiler, there is a different call for opening the file for binary out. I have found that instead of fopen() one should use open() when using write() to stuff things out to a file. This probably goes back to my experience in programming on UNIX. Files opened with fopen() are streams which one usually sends output to with things like fprintf and putc. And open is for unbuffered read()s and write()s. Try to use open() on COM1 and see if that has any better success. -- Bob Meyer Calspan ATC seismo!kitty!sunybcs!cald80!bob decvax!sunybcs!cald80!bob