[ On Monday, April 26, 1999 at 21:35:59 (+0930), Brett Lymn wrote: ]
> Subject: Re: A solution for termcap lossage?
>
> I have looked, I am not convinced - ncurses does to some odd things
> which I do not believe to be correct.  I have looked at the X/Open
> curses specification, I know what is there.

I haven't looked too closely at the standards lately....

I was thinking though of some of the other less standard features, such
as libform, libmenu, libpanel, etc.  Perhaps they're in the Unix 98 spec
(I think they were in SVID Issue 3, but I can't confirm that).  I don't
know if you'd want to implement those features, but so long as you don't
you're only giving another reason for people to use and support ncurses.

> If the wheel fits better then repairs are in order.

That's far far far too subjective.

On my subjective side of the fence I can't imagine why anyone would
*want* to maintain the original BSD curses code when there's a whole
team of people dedicated to maintaining a much more modern and much more
widely used piece of "equivalent" or perhaps even "superior" code.  If
you have a personality conflict with someone on that other team and
can't stand to use the code they write then perhaps that's a reason,
though I don't know if it would be a good enough one!  ;-)

Objectively it's important to note that except for application-specific
capabilities, any termcap can be turned into a terminfo entry, but it's
not possible to go the other way around due to the additional
parameterized string features of terminfo source files, and because
there are some newer features in terminfo that termcap doesn't support.

I think anyone, such as myself, who has supported lots of esoteric
terminals with both termcap and terminfo in environments with highly
demanding applications (eg. word processors) will greatly prefer writing
and maintaining terminfo entries, though this is somewhat subjective
too.

Finally, though I don't personally care about this feature, I'll also
note that ncurses supports a C++ API as well.  I know little about it
except it was derived from the libg++ CursesWindow class, supposedly is
more advanced and capable, and that NCursesWindow could easily be a
superset of CursesWindow.

> I am wondering if you have looked at the changes...

I have read the basic announcements and change logs.  If it were not for
the fact that ncurses already exists and already has all these features
then I'd call those changes a "step in the right direction".  However in
comparison to ncurses they're simply too little, too late.  Almost
everyone I know directly who's still writing and/or maintaining
screen-based applications has either migrated to SysVr3/SysVr4 curses or
ncurses, or gone to a third-party commercial library, long ago.  Back
when I was doing this I even went to a commercial library and then back
to ncurses!

> Let's play with this for a while.  OK so we want to use the terminfo
> as per the Sun implementation so we can run some statically linked
> binary.  Fine and dandy.  Now, what is the format of the file that tic
> writes on the Sun?  Is the file architecture dependant?  Is the format
> consistent across vendors?  Are you really sure? How do we choose if
> it is not?

The ncurses-4.2 term(5) manual page says the following:

       The format has been chosen so that it will be the same  on
       all  hardware.   An  8 or more bit byte is assumed, but no
       assumptions about byte  ordering  or  sign  extension  are
       made.

   [[ ... ]]

       Despite the consistent use of  little-endian  for  numbers
       and  the  otherwise self-describing format, it is not wise
       to count on portability of binary terminfo entries between
       commercial  UNIX  versions.  The problem is that there are
       at least three versions of terminfo (under HP-UX, AIX, and
       OSF/1)  which  diverged from System V terminfo after SVr1,
       and have added extension capabilities to the string  table
       that  (in the binary format) collide with System V and XSI
       Curses extensions.  See terminfo(5) for  detailed  discus-
       sion of terminfo source compatibility issues.

Now, obviously there might be issues with the compatability environment
for OSF/1, and possibly for HP-UX, but there may be other ways to deal
with those problems; and besides, they're issues that ncurses
maintainers have to worry about.

> I cannot see where binary compatiability is broken.  There is an
> answer and that is setting up the emulation environment.  I know this
> to be inconvenient but that is part and parcel of emulating another
> environment.

Emulation environments cannot deal with staticly linked binaries except
by pulling in a totally redundant terminal database to go along with
them (and of course all the emulated environment's maintenance tools
too).  Double the admin work, for every admin in the same boat, for
nothing.

> For people running native code there is a bigger advantage in having a
> single capability database that has compatiable api's for both
> terminfo and termcap.  That is the terminal entries can then be
> consistent for both.  You do not have to remember to update both systems.

Sure!  Ncurses delivers that ability, complete with the choice of which
database the local admin is going to maintain, 100% compatability with
both databases, tools to convert back and forth (within the limitations
of the format, of course), and with the run-time option for individual
users to pick and choose which database format they want to use too
(highly advantageous for users who have a working capability entry in a
format that the admin doesn't want to support, especially when the users
are not skilled enough to manually translate).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>