Date: Tue, 1 Sep 1998 13:48:41 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Jens Bischoff <j DOT bischoff AT airbus DOT dasa DOT de>
cc: djgpp AT delorie DOT com
Subject: Re: SIGALRM question / Text in Graphics mode
In-Reply-To: <9809010939.AA16600@axe.bre.da>
Message-ID: <Pine.SUN.3.91.980901133815.27272E-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Tue, 1 Sep 1998, Jens Bischoff wrote:

> #ifdef unix    
>      signal (SIGALRM, sig_alarm);
> #endif      

I don't know what did you need that for, but please note that DJGPP 
defines both __unix__ and unix.  So this line gets compiled under DJGPP.

>    alarm (1);
>     while (' ' != getchar ());
>    return 0;
>   }
> 
> The signal handler should normally be called every 1 second.
> But what happens is that it is called only after a key is pressed.
> Is this a bug or a feature with DJGPP?

It's a feature.  `getchar' calls DOS and gets parked in the DOS call in
real mode until you press a key.  However, signal delivery in DJGPP is
deferred until your program is back in protected mode.  There's no other
safe way to deliver signals generated by hardware interrupts (like the
timer tick in your case) to DPMI programs. 

I suggest to take a few moments and read the documentation for the 
library function `signal' in libc.inf.  It explains these subtleties near 
the end of the `signal' page.

> (By the way: Another stange behaviour occurs when I replace the
> whole line that contains the "while"-statement with a simple
> "while (1);": The program hangs (CTRL-C does not work, no output is
> shown), but a "while (1);" works then. Why this?!?

As explained in the above-mentioned docs, signals are only delivered when 
your program touches its data.  "while(1);" is compiled into a tight loop 
that doesn't access any data.  Avoid such loops (and also loops that only 
access registers) in a program that employs signals.

> 2. ) When in Standard-VGA graphics mode, text output will be displayed 
>      on the screen, too. How can this be done in VESA/Super-VGA
>      modes (here the output is not shown) ?       

Use your own custom functions to write the text directly to the video RAM. 
Standard VGA modes are known to the BIOS, so when you print to the screen,
the BIOS WriteTTY function works correctly.  But the BIOS doesn't know
about non-standard modes.