Path: utzoo!attcan!uunet!husc6!mailrus!uflorida!gatech!mcdchg!ddsw1!karl From: karl@ddsw1.MCS.COM (Karl Denninger) Newsgroups: comp.unix.microport Subject: Re: term.c for rn on uport 286 Summary: 2.4 curses works for us here... what's the problem supposed to be? Keywords: rn, term.c, V/AT(286) Message-ID: <2209@ddsw1.MCS.COM> Date: 22 Nov 88 21:49:37 GMT References: <102@swamps.UUCP> <405@zinn.MV.COM> <153@tree.UUCP> Reply-To: karl@ddsw1.MCS.COM(Karl Denninger) Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 33 In article <153@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: >In article <405@zinn.MV.COM>, mem@zinn.MV.COM (Mark E. Mallett) writes: >> >> When I upgraded to 2.4 of System V/AT, I got segmentation violations >> out of term.c in rn. Because of the comments I'd read here about >> the new curses being buggy, I simply went back to the curses >> library from the previous release. Voila, no more segmentation >> errors. >Can anyone here second that curses is the source of the errors? I'd like some confirmation of that too.... or lack thereof. We've got AKCS, our conferencing package, compiled under the new 2.4 version, and didn't see _anything_ in the way of core-dump-on-init problems that others reported here. In fact, it seemed to work much better than the older, 2.3 version of the curses libraries... AKCS uses multiple windows on one screen (newwin()s) and lots of manipulation; I expected it to crash given the early reports. It hasn't been beaten up really well yet (we don't have 2.4, but one of our customers does and we built it there) but from what we can see here the early reports of curses-caused core dumps look like lots of smoke, but no fire. On the other hand, I haven't seen _any_ change in serial I/O behavior (at 9600 baud it still can't hack even a single incoming line w/o hardware assist of some kind). -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"