Mail Archives: djgpp-workers/1998/01/25/04:26:12
On Thu, 22 Jan 1998, Markus F.X.J. Oberhumer wrote:
> While I appreciate your efforts and understand your motivation
> behind this patch, I think that is not matured for inclusion
> into libc
We clearly disagree on this (if I thought like you, I would never sit
down to write that code). But since you haven't provided any
reasoning behind your opinion, I cannot respond to it. So we are left
with no possibility to arrive at some agreement as to what should be
changed in the code I submitted to have everybody, including you,
happy.
> it's just another dosish hack.
Many things in DJGPP look like ``another dosish hack''. The startup
code and the stub are full of such tricks, and many library functions
pull them as well. However, the reason is not ``immaturity'', but an
attempt to build a 32-bit, protected-mode, POSIX-compliant environment
on top of a 16-bit, real-mode DOS. There's no other way this can be
done except by such tricks. In fact, even MS hack DOS when they need.
For example, Windows 3.X patches DOS when it starts.
> The way to go is termios (fortunately the almighty POSIX argumentation
> seems to by on my side this time ;-).
The change I suggested does not contradict this. It offers low-level
facilities to make it possible for termios to support these features.
I also think that it is incorrect to make SIGQUIT support be dependent
on termios. Other signals obviously don't, and since termios, as
implemented in DJGPP, changes the console I/O in a fundamental way, it
would change behavior of interactive programs too much.
> Termios offers abstractions of all
> the things we need (VINTR, VQUIT, ISIG, ...). It probably needs to get
> coupled tighter with the keyboard handler, and there are some things
> to be done at startup (like quering KEYB.COM).
There's no way known to me to add code to the DJGPP keyboard handler
at runtime, as it provides no hooks where user-defined functions can
be called. The rules of hardware interrupt handling under DPMI are
complicated enough to make such hooks impossible without some heavy
bookkeeping which will punish every interactive program that doesn't
use termios.
So any attempt to extend termios without low-level support in the
keyboard handler would mean that you need to replace the default
keyboard handler. Nobody seems to be motivated enough to mess with
such low-level stuff these days. Which probably means that it is
futile to hope that somebody will ever extend termios with the current
state of affairs in the keyboard handler.
What I tried to accomplish was to make the default keyboard handler
have the minimal support for such extensions. This minimal support
includes a possibility for defining a key that generates SIGINT
(instead of having it hard-wired as Ctrl-C) and support for SIGQUIT.
This should IMHO make the future development of termios much easier.
> I don't know if someone has the motivation and skill to actually
> dig into this, but please no more rash libc extensions
IMHO, this attitide means stagnation. There are two ways of making
DJGPP move in the direction of your liking: either write the code
yourself, or convince others to change their code according to what
you think is right. So if you have specific suggestions for changes
in the code I submitted, please tell what they are. Asking for ``no
more rash libc extensions'' won't help: I'm working on this for far
too long to make it qualify as ``rash''.
> if you need it badly now then put it into emacs.
The main motivation for SIGQUIT was not Emacs, since it defines the
same handler for both SIGINT and SIGQUIT.
- Raw text -