Curses differences on 4.3 and Ultrix V2.2

[Every system needs one]

In article <38132 at yale-celray.yale.UUCP>, spolsky-avram at CS.YALE.EDU (Joel Spolsky) writes:
> In article <3711 at cheviot.newcastle.ac.uk> Peter_Cutting at newcastle.ac.uk (P. G. Cutting) writes:
> | 
> | I wrote a simple windowing system using Curses on a 4.3 machine. Eventually
> | it worked but now when I recompile it and run it on an Ultrix machine the 
> | windows get messed up. I have checked Termcap entries and STTY entries which
> | seem OK, and so I conclude that there are differences between Curses on the
> | two machines. Can any one back up this conclusion and maybe suggest where the
> | problem might be.
> 
> I also noticed that Ultrix Curses were weird. I am sure that Ultrix
> Curses are very different than (from?) System V Curses; they could
> also be quite different from BSD Curses. One problem I noted with
> Ultrix Curses is that only one highlighting mode is supported.
> 
> Joel Spolsky             bitnet: spolsky at yalecs     uucp: ...!yale!spolsky
> Yale University          arpa:   spolsky at yale.edu   voicenet: 203-436-1483
> "You can't expect to wield supreme executive power just 'cause 
> some watery tart threw a sword at you!!"

Use '-lcurses' instead of '-ltermcap' to get the additional highlighting
modes... this, of course, assumes you have good /usr/lib/terminfo/*
entries, an unlikely event, especially if you have televideo/wyse/liberty
hardware.

If you are using VTxxx terminals, use the '-nam' version.  ALL curses have
a well known bug with AM and XN terminals.  The assumption that a linefeed
is ignored after a carriage return is good enough to cause "vi" to work,
but is certainly not the way the things work.  VTxxx series terminals do
NOT "ignore the LF"; instead, they wrap before character 81, not after
character 80.  The assumption built into curses is that AM:XN terminals
do not work this way.

In the long run, you are better off writing your own system, especially
if you expect your program to be commercially viable.

A number of companies have taken this to exteremes, however, and have
rewritten the entire termcap/termlib concept and come up with their
own files (Wordperfect and Microsoft Word spring to mind).  This is
generally a bad approach, as debug time becomes nearly infinite unless
you own every terminal you run on.  Since it is unrealistic to expect
your end users to consult you prior to buying equipment, or to ignore
you if you recommend more expensive equipment, you lose.

A less extreme, but, IMHO, equally bogus approach is to include your own
termcap file.  This gets rid of all problems on equipment you own, and
allows you to update entries "borrowed" from someone else's unmodified
termcap, but eventually you will pay the same in technical support.
Besides, the assumption that all curses systems are created equal is valid.

To the first poster:  perhaps you need to flush your output file descriptors,
especially if you've duplicated them and are using more than one to talk to
the same device (frequntly done in initial home-brew window systems); you
are not guaranteed a particular flushing order unless you forcibly flush
your buffers or use on fd.  Flushing under BSD should be done anyway
(unless you set your output buffer way down, effectively flushing after
each write) to allow the system to do a single blocked writei() at the
kernel level -- much more efficient, and you'll look faster.


| Terry Lambert           UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry |
| @ Century Software        OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
|                   'I have an eight user poetic liscence' - me               |