Date: Sun, 25 Jan 1998 11:23:24 +0200 (IST) From: Eli Zaretskii To: "Markus F.X.J. Oberhumer" cc: dj AT delorie DOT com, djgpp-workers AT delorie DOT com Subject: Re: Request for comments: SIGQUIT in DJGPP v2.02 In-Reply-To: <199801222051.VAA05460@wildsau.idv.uni-linz.ac.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.