ronald@robobar.co.uk (Ronald S H Khoo) (03/23/91)
SCO's 3.2.0 Dev Sys terminfo curses seems to go crazy (*) when fed
8 bit characters -- Does anyone know if it's fixed in the rev 2.0
Dev sys, and if so, does anyone know how much the upgrade co$ts,
and more importantly, what the part number is ? (I got a *real dumb*
supplier -- quoting part numbers is the only way to get any sense
out of him -- and don't ask me to change suppliers -- managment
directive sez "buy from this sister company or else buy nothing" :-( )
Thanks for any help.
--
(*) "crazy" in this sense: with this program -
$ cat foo.c
#include <curses.h>
main()
{ initscr();
addch(0243);
refresh();
endwin();
}
$ cc -DM_TERMINFO foo.c -ltinfo
I expect a pound sign on an ISO Latin 1 terminal, or a u-acute
on a PC console. Instead I get a flashing blinking screen full of
carets. Sigh. Strangely enough, it *does* work when I add a -xenix
flag, but then GDB doesn't. Sigh.
--
Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)aw1@stade.UUCP (Adrian Wontroba) (03/24/91)
In article <1991Mar22.211749.13292@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >SCO's 3.2.0 Dev Sys terminfo curses seems to go crazy (*) when fed >8 bit characters -- Does anyone know if it's fixed in the rev 2.0 >Dev sys, and if so, does anyone know how much the upgrade co$ts, >and more importantly, what the part number is ? I believe that the dev system upgrade costs approximately 200 pounds. I'm afraid that I do not know if it will fix your curses problem, nor the part number. Phone SCO and ask? -- Adrian Wontroba, Stade Computers Limited. phone: (+44) 21 373 9546 uucp: ...!ukc!stade!aw1 other: aw1%stade.uucp@ukc.ac.uk snail: 14 Fourlands Avenue, Sutton Coldfield, West Midlands, B72 1YY, UK
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (03/25/91)
In article <1991Mar22.211749.13292@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >SCO's 3.2.0 Dev Sys terminfo curses seems to go crazy (*) when fed >8 bit characters -- >(*) "crazy" in this sense: with this program - > > $ cat foo.c > #include <curses.h> > main() > { initscr(); > addch(0243); > refresh(); > endwin(); > } >I expect a pound sign on an ISO Latin 1 terminal, or a u-acute >on a PC console. Instead I get a flashing blinking screen full of >carets. Sigh. Strangely enough, it *does* work when I add a -xenix >flag, but then GDB doesn't. Sigh. The bits above the 0x80 bits are attribute bits in 3.2 curses and include blink, underline and color. Look at /usr/include/tinfo.h at the A_..... definitions and the man page for curses. There is an A_ALTCHARSET bit you can set, but you may utlimately be disappointed in using the high 128 video characters. I only tried for three days before giving up (wanted to use the ruling characters). I tried the 'acs' stuff and everything else in TFM, terminfo.src and header files, but with no luck. I am still interested in doing this one day. Until then, I use the termcap curses, which does not support color or a host of other nice things, but you can write any video ROM character from 0x20 to 0xFF. ---------------------------------------------------------------------------- Warren Tucker, TuckerWare, Mountain Park, GA wht@n4hgf.Mt-Park.GA.US "The computer can't tell you the emotional story. It can give you the exact mathematical design, but what's missing is the eyebrows." -- Frank Zappa
ronald@robobar.co.uk (Ronald S H Khoo) (03/28/91)
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes: > > addch(0243); > >I expect a pound sign on an ISO Latin 1 terminal, or a u-acute > >on a PC console. > The bits above the 0x80 bits are attribute bits in 3.2 curses > and include blink, underline and color. Yes, but 0243 does not have bits 0x80 or above set. The problem is apparently not SCO's fault, but that AT&T's curses has a bug in waddch which causes sign propagation into the attribute bits :-( SCO's workaround (thanks for the mail! - SCO have some very good people who read this list and help with mail answers.) is to recast your code in terms of addstr() which apparently doesn't have this problem. (I haven't tried this approach) My fix, like yours, is to go back to termcap curses. The good news is that termcap curses comes with *source* (on the 4.3 reno freed files collection) so I'm adding the ACS_ stuff and maybe colour to it as well as making it 8 bit clean. Small bugs bite hard when you don't get source -- I don't have the skill to binary patch buggy libraries in a cost-effective timeframe. This is not a fault of the existing vendors, but of the market as a whole. Does anyone have a patch to fix this ? -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
macleod@cmllab.rgb.sub.org (Connor MacLeod) (03/29/91)
In article <1991Mar22.211749.13292@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) wrote: | SCO's 3.2.0 Dev Sys terminfo curses seems to go crazy (*) when fed | 8 bit characters -- Does anyone know if it's fixed in the rev 2.0 | | addch(0243); I think that's a problem of the addch(). Use addstr() instead and it'll work. This "problem" is _not_ fixed in SCO U DEV 3.2.2. Rgds -- Uwe Obst # {connor|macleod}@cmllab.rgb.sub.org (aka Connor MacLeod) # "Trust me, I know what I'm doing!" -- Sledge Hammer
mfp@sobeco.com (m.proudman) (04/11/91)
In <1991Mar22.211749.13292@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >SCO's 3.2.0 Dev Sys terminfo curses seems to go crazy (*) when fed >8 bit characters -- Does anyone know if it's fixed in the rev 2.0 [...] >-- >(*) "crazy" in this sense: with this program - > $ cat foo.c > #include <curses.h> > main() > { initscr(); > addch(0243); > refresh(); > endwin(); > } I find that the following works quite well, when making use of the IBM 8 bit character set on the XENIX console: int c; addch((chtype)(c&0377)); and also: char * p; addch((chtype)((*p)&0377)); I experienced problems similar to yours, and came up with this after a bit of playing. Perhaps someone can give a complete explanation as to why it works. Mark Proudman mfp@sobeco.COM | uunet!spectr!mark (514) 849 UNIX
pauld@stowe.cs.washington.edu (Paul Barton-Davis) (04/12/91)
its probably the fact that chtype is a long, not a char, and stores character attributes in one half, and the character value in the other. the curses.h header is pretty dumb about this, in that you can redefine chtype to be char or long yourself, despite the fact that the library has already been built with one type throughout. this also causes problems with the scrdump format - if anyone has been able to read a curses screen dump on a V/386 system, let me know how they did it, because the manual page does not match the format I found. it also refers to "chtype" despite the fact that the user has no idea of how chtype was defined when the libraries were built. -- Paul Barton-Davis <pauld@cs.washington.edu> UW Computer Science Lab ``to shatter tradition makes us feel free''
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/16/91)
As quoted from <1991Apr11.022708.11563@sobeco.com> by mfp@sobeco.com (m.proudman): +--------------- | int c; | addch((chtype)(c&0377)); | | and also: | | char * p; | addch((chtype)((*p)&0377)); | | I experienced problems similar to yours, and came up with this after | a bit of playing. Perhaps someone can give a complete explanation as | to why it works. +--------------- (char) is signed on 386/486 processors. So, (char) 0200 gets sign-extended to a (chtype) (actually, a (long)) with all the attribute bits set and probably some wild color specifications as well. Either mask against 0377 (or 0xFF, same thing --- or even 255) or use (unsigned char) types. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
larryp@sco.COM (Larry Philps) (04/17/91)
In <1991Apr16.010851.6047@NCoast.ORG> allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: > As quoted from <1991Apr11.022708.11563@sobeco.com> by mfp@sobeco.com (m.proudman): > +--------------- > | int c; > | addch((chtype)(c&0377)); > | > | and also: > | > | char * p; > | addch((chtype)((*p)&0377)); > | > | I experienced problems similar to yours, and came up with this after > | a bit of playing. Perhaps someone can give a complete explanation as > | to why it works. > +--------------- > > (char) is signed on 386/486 processors. So, (char) 0200 gets sign-extended to > a (chtype) (actually, a (long)) with all the attribute bits set and probably > some wild color specifications as well. Either mask against 0377 (or 0xFF, > same thing --- or even 255) or use (unsigned char) types. There is a compiler option (documented), -J, that will cause the compiler to change the default type of char from signed to unsigned. This should also fix things. --- Larry Philps, SCO Canada, Inc (Formerly: HCR Corporation) Postman: 130 Bloor St. West, 10th floor, Toronto, Ontario. M5S 1N5 InterNet: larryp@sco.COM or larryp%scocan@uunet.uu.net UUCP: {uunet,utcsri,sco}!scocan!larryp Phone: (416) 922-1937 Fax: (416) 922-8397