Messages in this thread |  | | Date | 02 May 1996 21:20:00 +0200 | From | (Kai Henningsen) | Subject | Re: signal(SIGFPE,SIG_IGN), possible solution? |
| |
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
|  |