Date: Thu, 4 May 95 11:57:48 MDT From: terry@cs.weber.edu (Terry Lambert) To: peter@bonkers.taronga.com (Peter da Silva) Cc: hackers@FreeBSD.org, terry@cs.weber.edu (Terry Lambert) Subject: Re: Screen print capability Message-ID: <9505041757.AA08447@cs.weber.edu> In-Reply-To: <199505040005.TAA17949@bonkers.taronga.com> from "Peter da Silva" at May 3, 95 07:05:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's not an SCO console if it doesn't allow the character set shifting, > > doesn't allow scan-code mode operation, doesn't support escape sequence > > reporting, doesn't support switching the character attribute between > > blink and high intensity for background colors, doesn't support ISO > > and SCO color selection escape sequences, or doesn't support scrolling > > when the 80th column/25th line character is written (the proper way to > > handle it is to remember the 79th character, draw the 80th at the 79th > > position, insert a character at the 79th making the 79th the 80th, and > > redrawing the 79th). > > I didn't see screen printing in that list, but if it's critical for SCO apps > then turn it on for SCO apps, but leave it off by default. Screen printing is not one of the features; what people were talking about was using "escape sequence reporting" (of screen contents) and doing the implementation that way. Personally I'm partial to the "ioctl for a hot key, ioctl to get screen contents" approach. > > Leaving out a feature because you find it morally repugnant isn't an > > option. There's a nice, clear "yes/no" line for compatability, and that > > would put you firmly on the "no" side. > > OK, do you plan to support Xenix 286 emulation? If compatibility is a yes/no > matter then leaving that out puts you clearly on the "no" side. That means > you need to support Xenix shared memory and Xenix semaphores, which use > special files in the file system. > > No, I don't expect that (though it *would* be a killer app... we're keeping > a bevy of Xenix boxes alive for legacy support), but it does mean that SCO > compatibility isn't a nice, clear "yes/no" line after all. I think the line is per application. The 286 emulation does push a number of things over the line to "no". We aren't really talking about moving the line, we're talking about looking at a rather raggedy line and then examining the point of closes approac to see if anything's on the other side of it or not. I'd have to say that the console is one thing that sticks its nose way, way out there. The 286 emulation is less of a problem, since there are less apps depending on it than are depending on identical console function. On the other hand, I'd say that both are actually desirable, though the console is more desirable. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505041757.AA08447>