Getchar w/wout echo

Wed Aug 31 16:12:28 AEST 1988

In article <313 at quintus.UUCP>, ok at quintus.uucp (Richard A. O'Keefe) writes:
> In article <65474 at sun.uucp> swilson at sun.UUCP (Scott Wilson) writes:
> >>Who _cares_ how much baggage comes with Curses?
> >I care, other people care.  Some of us are developing C programs
> >on machines like the Macintosh where you are trying to fit your
> >OS stuff, your C programming tools, and your C project onto two
> >800K floppies.  This is comp.lang.c, not comp.lang.c.on.a.big.machine.
> >with.megabytes.of.disk.space.and.maybe.paging.  Size is important.
> >And curses is not universally available.

Bravo, Scott!

> My word, how things have changed!  Little wee IBM PCs running MS-DOS
> are now "big.machines.with.megabytes.of.disk.space.and.maybe.paging"!
> (I believe that there is a version of Curses for the Atari ST, too.)
> If you are working on a Macintosh, POSIX features aren't going to help
> you one tiny little bit either.

No, we're talking curses, not something else.  Does AT&T say this package
of which you speak is curses?

> What in the world is wrong with taking the bits of the Curses *interface*
> that you need, specifically the functions echo() and noecho(), and using
> them in your code?  Ok, in the Macintosh version of your program, you will
> have to write a small Macintosh-specific file to implement them.  Do
> everyone a favour:  post the sources to comp.sys.apple.mac or whatever it
> is called.  That's the way to produce a de facto standard, and that's how
> we'll get echo control in the next version of ANSI C.

Urk.  "what's wrong?"?  Try Copyright AT&T.

Besides, curses is seriously buggy in a number of places, like:

	XS,XN,AM,SG,UG,GG,tputs(), etc.

I can site specific examples; the one you are probably curious about, is,
however, tputs().

	1) It doesn't necessarily cause an I/O to occur in a single write
	   operation.  This is BAD as transparent printing gets more
	   popular, and seriously kills paged-screen multiple sessions.

	2) Not all implementations know about pad characters, and instead
	   print the numbers on the screen.

The tgetent() does not malloc() the save area; you have to know how big
the maximum area is going to be beforehand when you're coding your own
code; that's bad enough... but if some idiot has a monster termcap/info
entry, curses can't be made happy without kludges.

Curses depends (according to SVID) on the terminfo file.  This is a kludge.

	1) It is not extensible.  It depends on a struct compiled into
	   libcurses.

	2) It is hard to fix.  Most manufacturers do not provide source.

	3) Many terminal definitions are wrong; specifically, SCO Xenix
	   is the only system I've seen that has gotten the Wyse-50 and
	   the Televideo 950 graphics correct, and I had a lot to do with
	   that.  True, it's usually broken in termcap, but at least I
	   can fix that.

	4) It will not work with a true VT100 terminal or emualation.
	   Since VT100's are probably the most emulated terminal, this
	   is stupid, and obviously a result of poor or no testing.  I
	   expect a company like AT&T to be able to afford one of each
	   of the terminals they say they support, considering what they
	   are charging for a liscence.  To get it to work, you have to
	   lie and say you are on a 'vt100-nam' or remove the "AM" attr.

Standout is not properly handled.  In most cases, there is a "protect"
bit which can be used in lieu of reverse to at least correctly emulate
standout.  This is true of all Wyse and Televideo terminals.

Curses is brain-damaged with windows.  The window implementation is
bad in that it

	1) Does not understand hardware scrolling (though this is more
	   a terminfo fault, in that it can not be extended to fix
	   this deficiency anyway).

	2) Can not move a window in the background while leaving another
	   in the foreground untouched.  This is the fault of the model
	   used to implement the window and it's memory mapping.  Layered
	   windows were chosen to avoid "excessive memory allocation" for
	   the save buffer area.  The point of diminishing returns, to
	   correct this misinformation, is when all windows are n x m or
	   larger where n+1 x m+1 is the virtual screen size.

There are no field input primitives.

Typical code sizes change from:

	270k -> 288k
	508k -> 527k

when libcurses  is used instead of libtermcap.  While it is true that
disk space is no longer a problem on most systems, space on distribution
media is limited.  This is an 18-19k increase, and can force an additional
disk if there are several executables and distribution space is already
tight (it has in 3 cases at our company, due to the target system no
longer supporting termcap).

Internationalization is hard when most implementations use the 8th bit
for their own nefariousness (using a short yields 9 attr bits that way).

It is ridiculous to think that a company would ship a product *HEAVILY*
dependant on it's display without writing their own code or buying
someone elses.

Need I say more?

<Unflame without much enthusiasm>

| 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               |