Re: signal(SIGFPE,SIG_IGN), possible solution?

Kai Henningsen (kai@khms.westfalen.de)
02 May 1996 21:20:00 +0200


hahn@neurocog.lrdc.pitt.edu (Mark Hahn) wrote on 30.04.96 in <199605010339.DAA13065@gina.uni-muenster.de>:

> nonsense. the poster's asserting that there's a lot of color tty
> handling code in the kernel. offhand, I suspect it's smaller than
> he thinks (just as the split-the-kernel whiners thing that the other
> architectures take up significant space.) but he's right about one
> thing: it should probably be in some shared library, rather than
> in the kernel.

Complete nonsense. This is something you cannot (reasonably) do with
library code.

What you _can_ do with library code, is already done so - see ncurses.

To do the rest, you'd have to directly access the video memory from that
library. All output to the screen would have to be special-cased to go
through that library. The idea is completely insane.

As to it being not much code, in that you are correct. Have a look at it.
Color support in a text screen driver is trivial to do. It's no more
difficult than support for other attributes, like brightness or
underlining. You need to have a current attribute value anyway, the
hardware wants to see it.

MfG Kai