Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!utah-gr!uplherc!sp7040!obie!wsccs!terry From: terry@wsccs.UUCP (Every system needs one) Newsgroups: comp.lang.c Subject: Re: Getchar w/wout echo Summary: Curses sucks Message-ID: <628@wsccs.UUCP> Date: 31 Aug 88 06:12:28 GMT References: <371@marob.MASA.COM> <225800052@uxe.cso.uiuc.edu> <65197@sun.uucp> <313@quintus.UUCP> Lines: 123 In article <313@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes: > In article <65474@sun.uucp> swilson@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? | 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 |