Xref: utzoo comp.terminals:2632 comp.unix.programmer:1210 Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!uunet!usaos!xenitec!sco!staceyc Newsgroups: comp.terminals,sco.opendesktop,comp.unix.programmer Subject: Alternate character modes on magic_cookie_glitch terminals (long) Message-ID: <9103010801.aa29309@xenitec.on.ca> Date: 1 Mar 91 13:01:31 GMT Sender: @usaos.uucp Organization: The Santa Cruz Operation, Inc. Lines: 133 Return-Path: To: scoodt-local@xenitec.on.ca X-Mailer: SCO System V Mail (version 3.2) Resent-By: mmdf@xenitec.on.ca Xref: xenitec comp.terminals:1825 sco.opendesktop:592 comp.unix.programmer:1163 Keywords: qvt101, freedom100, curses Message-ID: <10513@scolex.sco.COM> Date: Thu, 28 Feb 91 20:26:18 GMT References: <1502@rascal.UUCP> <10248@scolex.sco.COM> <1504@rascal.UUCP> Sender: news@sco.COM In article <1504@rascal.UUCP> theo@rascal.UUCP (T. Kramer) writes: >In article <10248@scolex.sco.COM> staceyc@sco.COM (Stacey Campbell) writes: >>You must define an acsc string for your terminal. > >Unfortunatly ACS is not portable across UNIX V.2, XENIX V.2 etc. This is >however, a strict requirement for our code. ACS_ macros work fine on both Xenix 2.3.2 (and later) and SCO Unix with the proviso I mentioned in the previous post that the Xenix tic command does not grok acsc in terminfo source files; in which case use the Unix tic and transport the ticced file back to Xenix. Some SCO products are now moving to curses color, so we develop on Unix and ship the color applications and color terminfo files for Xenix. >I would agree with you >that if I used the ACS_ defines I would not need (w)attron and (w)attrof, >but because our code must be portable including, hopefully, our terminfo >source files I can not depend on ACS_ defines. I've developed a fair bit of public domain code that compiles on BSD, System V.2, V.3.0, and V.3.2 curses and have come to the conclusion that it is very important to follow the manual for System V.2 and System V.3.[0-2] curses. Trying to fake out the ACS_ characters to maintain code portability with non-System V curses can be done, but because non-System V curses doesn't have a generally recognized way of storing ACS information, you will have to develop a system that works for every single terminal you plan on supporting. I usually find myself writing the following code; #ifdef ACS_HLINE box(win, 0, 0); #else UseCruftyBoxHack(win); #endif If you aren't willing to use ifdefs or use a seperate source pool (as seems to be the case) then adding, for example, color to a curses portable application becomes near impossible. >>"REMEMBER THAT sgr AND sgr0 MUST ALWAYS BE SPECIFIED". > >I need the call to (w)attrof as in my actual code I need to output >normal character information after for example having painted a box on >the screen. If you absolutely must use non-standard methods to put alternate characters on your screen then wattron() and wattroff() _will_ do what you want. >The point of my request for >help, however, is why does SCO Opendesktop Development System curses >not output an \E% or \E%% or \E\% but does output AA and BB and \E$ and ... >for the (w)attroff call? I seriously believe that this is a serious bug >in the curses package which makes it difficult if not impossible for me, >and I am sure many others who have selected curses for portability, to >generate production binaries using the SCO UNIX and Opendesktop development >systems! Which prompted me to go back to your original post and try out your program and terminfo file again. :-) The reason the qvt101+so entry is failing isn't exactly glaring, but once you see it all becomes clear. Your qvt101 entry contains the numeric capability xmc#0. The guy who wrote System V.3.2 curses claims that it deals with magic cookies correctly (he posts occasionally to Usenet), though I have yet to see a scrap of documentation that explains what is required of the terminfo file and the curses program (obviously something, otherwise your program would work). I am somewhat confused by the 0 in xmc#0, the manual says the numeric value to xmc is the "number of blank characters left by smso or rmso". If this value is zero then it would seem that there is no magic cookie required, therefore xmc should be removed. Perhaps the 0 is special. Either way, if xmc#0 is removed from the qvt101+so terminfo file the program will emit rmacs. The curses source implements in a number of places; if (! magic_cookie_glitch) turn_off_attributes(); I've added comp.unix.programmer to the Newsgroups line because I know there's some folks there who have dealt with this problem. A simple way to fix the problem is to see if your terminal supports _any_ attributes without magic cookies, then remove xmc and set smso and rmso to that attribute, for Wyse 50s I think this attribute is protected mode. Here is a program that demonstrates the problem; #include int main() { int index; int y, x; initscr(); addch(ACS_ULCORNER); for (index = 1; index < 20; index++) addch(ACS_HLINE); addch(ACS_URCORNER); refresh(); endwin(); } Here's the original terminfo file (with acsc and sgr0 added); # Terminfo source code for my (theo's) qvt101 terminal qp|qvt101+so|Qume qvt101 + terminal, cr=^M, cud1=^J, ind=^J, bel=^G, is2=\E0P\Ew\E.4\E(\EC\E%\EX\E\047\E+\Ef^M\Eg, clear=\E+, tbc=\E3, hts=\E1, sam, cols#80, lines#24, cr=^M, nel=^J, xmc#0, khome=^^, kcuf1=^L, kcub1=^H, kcud1=^J, kcuu1=^K, cup=\E=%p1%' '%+%c%p2%' '%+%c, cvvis=\E.1, cnorm=\E.4\E*, cbt=\EI, cud1=^J, cuf1=^L, cuu1=^K, home=^^, cub1=^H, ul, smso=\E), rmso=\E(, el=\Et, ed=\Ey, il1=\EE, dl1=\ER, dch1=\EW, ich1=\EQ, smul=\EG8, rmul=\EG0, rmacs=\E%%, smacs=\E$, sgr0=\E(\E%%, kf1=^A@^M, kf2=^AA^M, kf3=^AB^M, kf4=^AC^M, kf5=^AD^M, kf6=^AE^M, kf7=^AF^M, kf8=^AG^M, kf9=^AH^M, kf0=^AI^M, acsc=kkllmmjjnnwwvvuuttqqxx, -- Stacey Campbell Internet: staceyc@sco.com UUCP: {uunet,ucscc,att,sq,altos,lotus,sun,microsoft}!sco!staceyc