Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!uunet!cs.dal.ca!dalcsug!erskine
From: erskine@dalcsug.UUCP (Neil Erskine)
Newsgroups: comp.unix.xenix
Subject: Re: SCO 2.3 curses bug 2
Summary: Actually a device driver bug. Workaround (poor one).
Message-ID: <366@dalcsug.UUCP>
Date: 1 Apr 89 23:13:36 GMT
References: <74@estinc.UUCP>
Reply-To: erskine@dalcsug.UUCP (Neil Erskine)
Organization: Math, Stats & CS, Dalhousie University, Halifax, NS, Canada
Lines: 61

][b

In article <74@estinc.UUCP> fnf@estinc.UUCP (Fred Fish) writes:
>
>/*
> *	This little program demonstrates what I believe to be a bug
... short curses program that ends with reverse video spaces appearing
    where they ought not...
>

	The bug is actually in the console device driver, which does
not perform the ANSI standard actions for ANSI standard sequences. The
bug arises with the clear sequences, which are SUPPOSED to remove all
graphic symbols (characters) and associated graphic renditions
(character attributes) from the affected area.  Instead it effectively
pushes the current cursor position, writes spaces into the affected
area, and pops the cursor position.  The result, if you happen to be
in reverse video mode, is that reverse video spaces are written in the
area you ordered cleared.  Curses assumes (quite reasonably) that the
'terminal' works properly.  The same problem arises when you write a
newline on the last line of the screen while in reverse video mode:
You end up with a complete line of reverse video spaces at the bottom of
the screen.

	Easy way to recreate: type to the shell \E[7m\E[K\n
replacing \E with the ESC code, and \n with RETURN.

	I have reported this bug a few times per year, including
references to ANSI documents (page/section/paragraph ad nauseum),
since 1984 (Xeinx-86), but SCO shows no interest in repairing it, even
though they recently 'rewrote' the damn thing (or so they claim).
A couple of times SCO admitted that it was a bug, a couple of times
they said "wait for the next release, and let us know if the problem
is still there", and a couple of times they said it "might be a bug,
I dunno". (Notes in quotes are the gist only, not true quotes). They
have never said they would fix it.

	It is interesting to note that when IBM Xenix was being
distributed, and I reported the identical problem to IBM, THEY
admitted that it didn't work according to ANSI standard (but then
weaseled out of fixing it by saying that they didn't claim to
implement the ANSI standard; the fact that escape sequences and names
matched the ANSI sequences and names was coincidental).  SCO however
DOES make the claim that they implement that standard.  Can ANSI take
action against a company falsely claiming to support an ANSI standard?

CONCLUSION:
Do not ever expect to get a version of curses from SCO that works around
SCO's bugs.  They aren't interested.  At the company I work for we ended
up dumping SCO's curses and writing our own. A workaround that works most
of the time (at the expense of having reverse video disappear sometimes)
is to code \E[0m at the beginning of all your clear sequences for the
console.

Postscript:
	On the whole we were fairly pleased with SCO's support. Their
product has never been particularly slick, but it usually works.  They
just don't care to play with making things work exactly right;  almost
right seems to be close enough for them. Their sales have proved this
attitude to be a profitable one.

||!][b