lkml.org 
[lkml]   [1996]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.121 / U:2.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site