Curses and portability question.

Phong Vo[drew] kpv at ulysses.att.com
Wed Dec 12 02:10:57 AEST 1990


In article <DRACK.90Dec10132800 at diablo.titan.tsd.arlut.utexas.edu>, drack at titan.tsd.arlut.utexas.edu (Dave Rackley) writes:
- In article <1990Dec10.110403.139 at vax1.mankato.msus.edu> accwork at vax1.mankato.msus.edu writes:
- 
- >I am writing a program, which i hope to maintain a high level of portability. 
- >But i also want to some screen management.  I was planning on using curses.  Is
- >this a "good" choice ?  Is their something that is more standard ?  I hope to
- >keep the portability accross a vax, and a pc.  So is their any chance of this >?
- 
- >   Brian D. Goecke
- 
- When faced with this situation I chose to use ANSI escape sequences
- instead of curses.  VAXen with VMS and DOS machines have very similar
- escape codes.  Of course when you do this, screen management is up to you.
- 
- Just my two cents worth :-)
- 
- | David Rackley		        |                                             |

This is very bad advice. Escape codes are typically defined by the terminal
being used, not the OS! And, there are a hell of a lot more different types
of the former than of the latter. There are curses versions that have been
ported to DOS and VMS. You should at least look into that first. In addition,
curses is really two libraries, a high level one for managing the screen,
and a low level once for getting escape codes and setting up interaction modes.
On BSD UNIX systems, the low level library is libtermcap which is separated
from libcurses. On SysV machines, both libraries are merged into libcurses.
So if you don't want the overhead of high level curses code (which could be
significant if you are not using the right version of curses), you should
at least use its low level code for defining escape sequences. This gives
you "transparency" with respect to terminal types which in a normal day work
may be even more important than "portability" with respect to OS or machine types.



More information about the Comp.lang.c mailing list