I am trying to create a viewer program like mc's.
I need to display Full 8-bit characters, like it does.
I tried using ncurses, without success.
Is there a way to do it with slang (mc uses it instead of ncurses or with
what's the main differance between ncurses & slang?
what can I do with one, that cannot be done with the other?
which one is simpler to use?
which one producess better performance?
btw, sorry about the number of questions in one post. :)
: I need to display Full 8-bit characters, like it does.
: I tried using ncurses, without success.
: Is there a way to do it with slang (mc uses it instead of ncurses or with
Midnight Commander works properly with either slang or ncurses.
: what's the main differance between ncurses & slang?
ncurses follows a standard.
: what can I do with one, that cannot be done with the other?
nothing (with time). they both talk to serial terminals or emulations of same.
: which one is simpler to use?
: which one producess better performance?
they're pretty close in performance (slang cuts a few corners, and ncurses
is a little smarter)
The current version of ncurses is 4.2
There's an faq at
> I am trying to create a viewer program like mc's.
> I need to display Full 8-bit characters, like it does.
> I tried using ncurses, without success.
8bit-ascii and alternate character sets are always tricky and not much
> Is there a way to do it with slang (mc uses it instead of ncurses or with
MC , as well as Lynx, may use either of them optionally.
> what's the main differance between ncurses & slang?
Slang has a more portable color handling tha ncurses.
> what can I do with one, that cannot be done with the other?
> which one is simpler to use?
Slang is simpler to use for single-windowed programs, as it lacks direct
support for tiling, subwindows and pads which causes overhead.
(slang can emulate those features though)
If one wants those features or other ascii-widget sets (menus, forms, scroll-
tables, checkboxes, inputboxes, ...) there are more reusable libs for ncurses.
(libmenu, libforms comes with ncurses, libcdk by M.Glover and libXterminal by
Acostiachiaie can be found e.g. on sunsite, tvision (like turbovision which
comes from the Turbo Pascal UI).
For slang there is a toolkit called newt, which i've only seen as part of RH
> which one producess better performance?
Slang (if one doesn't need the multi-windowing features).
Without an example, I can't tell why: slang handles only the
back-color-erase style of color model supported by rxvt and XFree86 xterm.
It also won't handle a genuine dumb terminal (not an emulator) because it
doesn't implement delays. It also makes assumptions about the terminfo
contents that tend to speed it up in some cases, but detract from portability.
I am not sure what you mean by `full 8-bit characters'. Are you
trying to draw lines or characters from other non-english languages?
What character set do you want to use? Iso-Latin-1? Does you
terminal support characters in the range 128-160? Or does it
interpret such characters as control sequences? By default, slang is
8-bit clean and sends characters in the range 160-255 to the terminal
as-is. This is configurable with the slang variable
>what's the main differance between ncurses & slang?
>what can I do with one, that cannot be done with the other?
I wrote slang because I did not like the (n)curses programming
interface, and because ncurses under linux was buggy (this is nolonger
true). All slang's SMG (Screen Management) function and variable
names are prefixed with `SLsmg_', e.g., `SLsmg_refresh', whereas
curses uses a variety of names with no particular naming convention
(e.g., `raw'). SLang's SMG interface is more platform independent and
will also work on MSDOS, OS/2, VMS, Amiga, BEOS, and Unix. One
advantage of curses is that it has a higher-level interface for panes,
etc... However, the NEWT package from redhat provides a high-level
windowing library for slang. In addition, curses is available as a
standard library on most unix systems whereas slang is a separate
>which one is simpler to use?
They are probably the same.
>which one producess better performance?
It depends. For several years, the performace of slang was much
better. I have heard that the performance of the latest version of
ncurses is just as good as slang.
>btw, sorry about the number of questions in one post. :)
No problem. But keep in mind that I am biased since I am the
author of slang. Of course the same goes for the ncurses maintainer.
You may be better off getting some advice from people who have used
both libraries. Unfortunately, most people have never heard of slang.
I do not understand your criticism. Should emacs be criticised for
not being a vi clone and not following some standard for a conforming
vi implementation? Perhaps one should discard vim because it's not
TECO or some earlier editor. ncurses is a curses clone and so it must
follow the standard for curses implementations. The slang library is
not based on curses nor does it try to mimick the curses API. Thus it
does not have to follow any existing standard any more than the very
first curses library had to follow one. You are comparing apples and
: I do not understand your criticism. Should emacs be criticised for
: not being a vi clone and not following some standard for a conforming
: vi implementation?
Yes. For one, the emacs user will not be able to use some machines
that only have vi. It's not a technical point against emacs, of
course, but it is nonetheless a drawback for *some users*.
: Perhaps one should discard vim because it's not
: TECO or some earlier editor. ncurses is a curses clone and so it must
: follow the standard for curses implementations. The slang library is
: not based on curses nor does it try to mimick the curses API. Thus it
: does not have to follow any existing standard any more than the very
: first curses library had to follow one. You are comparing apples and
: oranges here.
As of today, an important advantage of C over C++ is its standardization,
which provides significant levels of portability across different
implementations. (I have no doubt C++ implementations will catch up,
just as C implementations gradually left K&R C for ANSI C.)
This has nothing to do with the technical qualities of C++, but it
has to do with the practical usability of C++, *as of today*. (If
the C versus C++ comparison irks you, feel free to replace C++ with
any other new language in the process of standardization.) Whether a
terminal I/O library is curses-compatible or not is of importance,
because of the portability advantages compatibility can offer. A
de jure standard is also usually more stable - look at the differences
between versions of Java, and the amount of work required to port
from one to the next.
This doesn't mean innovation should never happen, mind you, just
that it *can* be a valid criticism, in certain contexts.
I disagree. SLang is NOT an implementation of curses, nor is it a
version of curses. If you want to make an analogy with computer
languages, then do not use versions of java for your example. Instead
compare perl and fortran, or lisp and C, or C++ and smalltalk.
-- of course, if slang's curses implementation is not intended for use
in porting curses applications, this is not a criticism.
Be aware that some unices (like SCO) provide a terminal character
mapping. It is intended to switch character codes sent to the terminal
(or received from it) to e.g ISO-Latin-1 and the terminal's character
map. These filters also may send ESC-sequences to switch the terminal's
character map. For this mapping is done down in the system and not in
the application, it's sometimes confusing during debugging.
from SCO's "man mapchan":
The mapchan utility configures the mapping of information input and output.
mapchan is intended for users of applications that employ languages other
than English (character sets other than 7-bit ASCII).
mapchan translates codes sent by peripheral devices, such as terminals, to
the internal character set used by the SCO OpenServer(TM) system. mapchan
can also map codes in the internal character set to other codes, for output
to peripheral devices (such as terminals, printers, console screen, etc.).
Note that PC keyboard configuration is accomplished through the mapkey(M)
Also depending on the used terminal, character codes from ASCII 128 to
159 may be used as control characters (same meaning as ASCII 0 to 31).
Check your terminal's manual for more detail.
I had no problems printing characters > 160 using curses, as this (very
old) code still works:
for (i = 32; i < 256; i++)
if ((i >=32) && (i <= 127) || (i >= 160) && (i <= 255))
mvprintw(y, x, "%03o %c", i, i);
y += 1;
if ((y >= 24) || (i == 127))
y = 2;
x += 8;
> Is there a way to change the control sequences of the terminal, so it won't
> interpret the characters as control sequences? maybe put them all after
> sending ^[ 3 times or somthing (so I could still use the terminal
> abilities, and not lose the portability) ?
This depends on your terminal, so you'll loose portability when relying
> Or maybe I should display only 'dots' instead of control characters (like
> many other programs do, and lose the ability to distinguish between normal
> dots and control characters or between the control characters themselves?
Always a good idea, since random control sequences may screw most
terminals really up.
This is what I normally use to display binary contents: for normal
characters I just print them. Control characters I print in reverse
mode, so for an ESC I print a reverse [, an ASCII 1 (^A) will display as
an reverse A. 8-Bit control characters (ASCII 128 to 159) will be
Annother way is to dump the characters like the "od -c" command does:
0000000 L 001 004 \0 225 367 222 + \0 \0 \0 \0 \0 \0 \0 \0
0000020 034 \0 017 001 \v 001 \0 \0 ( 255 002 \0 024 261 \0 \0
0000040 4 030 \0 \0 324 \0 \0 \0 320 \0 \0 \0 370 \r @ \0
0000060 . t e x t \0 \0 \0 320 \0 \0 \0 320 \0 \0 \0
0000100 ( 255 002 \0 320 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0