Mail Archives: djgpp/1998/01/13/03:58:11
On Mon, 12 Jan 1998, George Foot wrote:
> Almost every aspect of Allegro works through a custom keyboard handler
> so almost all Allegro programs would probably be safe. I can't think
> of any reason to use DOS/BIOS/libc routines when Allegro's more
> flexible routines are available.
Somebody might be using the graphics facilities of Allegro without its
keyboard handling. I wanted to know how many applications do that.
Unfortunately, I didn't get any replies about that. I guess I should
have made my subject more catchy, like "Will DJGPP v2.02 break your
programs?". Hmm, that's a thought...
> : The only programs that will be affected are those who read their input
> : either through DOS in text mode, or through the BIOS interrupt 16h,
> : *and* bind Ctrl-\ to some action.
>
> I'm not sure about that `*and*';
If a program doesn't bind Ctrl-\, there's nothing wrong in aborting it
when it is pressed. It is the same as aborting a program when
Ctrl-BREAK is pressed, only with another key.
> there's also the possibility of
> hitting Ctrl-\ by accident. This is probably very dependent on
> keyboard layout; on a UK keyboard the backslash key is right next to
> the left shift key (left of Z), and I have hit that key combination at
> rather awkward moments on Unix systems.
But the same will happen on Linux when it is run on a UK machine,
right? So this is just a feature (possibly a misfeature for some
people) of the Unix compatibility, just like, say, globbing of the
command-line arguments which surprises some people when they say
something like "foo x*y*z*z*y".
> The main problem would probably be where an application has a
> reasonable amount of data which would normally be saved before exiting
> -- SIGQUIT would cause all that data to be lost. However I think that
> anyone writing such an application would probably disable C-c anyway
> for the same reason.
They should; and the same will happen when Ctrl-BREAK is pressed if
SIGINT isn't caught.
> Would it be better
> to use a crt0 flag, as for the sbrk algorithms? Then SIGQUIT could be
> disabled by default for normal djgpp programs, but Unix ports would
> just need an added global variable which may already exist anyway --
> in which case it would just be an extra flag ORed onto the end of it.
I don't see how this is better than to have DJGPP ports of Unix
programs that need SIGQUIT include some DJGPP-specific code to turn
the signal on. Setting a flag in _crt0_startup_flags is only one line
of code, but so is the following:
__djgpp_set_sigquit_key (0x042b);
The above is all that's needed to turn on SIGQUIT generation. I
wanted to avoid even a single line if it isn't necessary. However,
the few replies that I got seem to indicate that this issue is
somewhat controversial, and DJ is uneasy about enabling it by
default. So it seems like SIGQUIT will by default be ignored (i.e.,
its SIG_DFL action will be to just return), and applications that need
it will have to turn it on by calling `signal' with a non-default
handler.
Anyway, thanks for the feedback.
- Raw text -