From: j DOT aldrich6 AT genie DOT com
Message-Id: <199606092215.AA004898549@relay1.geis.com>
Date: Sun,  9 Jun 96 22:18:00 UTC 0000
To: djgpp AT delorie DOT com
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Subject: Printer Error (was Re: Listing

Reply to message 3246794    from ELIZ AT IS DOT ELTA. on 06/09/96 10:02AM


>> Getting programs to output to both the screen and a file at the same
>> time can get interesting, though.  If that's what you want, it'd take
>> something a lot heavier than a simple command-line switch.
>
>Actually, this is not too heavy.  The FAQ describes how to accomplish
>this in section 6.9.

All that section does is describe how to use 'redir', and that's not what
I was talking about.  I was thinking specifically about the problem of
having a program's output to any given stream echoed to two places
(screen & file) simultaneously, without writing two fprintf() statements
each time the program wanted to output something.

Believe it or not, I actually created a program and header file that
allows this to occur, by declaring wrappers for all the standard
character output functions (*printf(), *puts(), putchar(), putc(), etc.).
You call a function to initialize the print echo, and then whenever you
call the wrapper functions, they do the work.  It's not really all that
complicated, but I had to explore the 'va_list'-related functions quite
thoroughly before I got it figured out.

Actually, there was one small problem that I was having with the
program, and maybe you or Charles can help me out.  A while back,
there was a big flap about the way CWSDPMI handles int 24h by
silently failing the DOS call, instead of displaying "Abort, Retry,
Explode".  There was also a patch posted on the list that was
supposed to fix some erroneous behavior with the stdout and stdprn
streams.   Well, I got and installed the patch, but after doing so
encountered another problem.  If I told the program to output to stdprn
when my printer was not turned on, then the first call to fprintf using
stdprn would cause a SIGSEGV.  Note that this is its behavior _after_
installing the patch and updating libc.a.

After some further experiments, I have determined that the problem
does not occur under Windows (it just fails the call like it's supposed
to), and after getting the SIGSEGV under DOS, the computer crashes
when I try to load Windows.

Here's sample code and output that demonstrates the problem.  I
have a laser printer connected to LPT1, but that doesn't really
matter because the problem only occurs when the printer is turned
off.

/* test2.c
 * Demonstrates erroneous? behavior of fprintf( stdprn, ... )
 */

#include <stdio.h>

int main( void )
{
    if ( fprintf( stdprn, "Testing printer echo...\n" ) < 0 )
        printf( "Error writing to printer.\n" );
    else
        printf( "Printer ok.\n" );
    return 0;
}

C:\CPROGS>gcc -Wall -g -O -o test2.exe test2.c

--- Under Windows 3.1 DOS shell ---

C:\CPROGS>test2
Error writing to printer.

--- Under DOS w/CWSDPMI ---

C:\CPROGS>test2
Exiting due to signal SIGSEGV
Page fault at eip=00006168, error=0006
eax=00000000 ebx=ffffffff ecx=00007f14 edx=00000054 esi=00000000 edi=00007f14
ebp=000462a4 esp=00046294 cs=00e7 ds=00ef es=00ef fs=00cf gs=00ff ss=00ef
Call frame traceback EIPs:
  0x00006168  __flsbuf+60
  0x000041da  __doprnt+170
  0x00001f2d  _fprintf+105
  0x00001597  _main+23, line 9 of test2.c
  0x00001aeb  ___crt1_startup+115

My system configuration and DJGPP setup are correct - I've been through
that enough times.  :)

John