From owner-freebsd-hackers Thu May 4 11:16:23 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA18432 for hackers-outgoing; Thu, 4 May 1995 11:16:23 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA18425 for ; Thu, 4 May 1995 11:16:21 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA08447; Thu, 4 May 95 11:57:48 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505041757.AA08447@cs.weber.edu> Subject: Re: Screen print capability To: peter@bonkers.taronga.com (Peter da Silva) Date: Thu, 4 May 95 11:57:48 MDT Cc: hackers@FreeBSD.org, terry@cs.weber.edu (Terry Lambert) In-Reply-To: <199505040005.TAA17949@bonkers.taronga.com> from "Peter da Silva" at May 3, 95 07:05:43 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > > 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.