Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Apr 95 17:46:46 MDT
From:      terry@cs.weber.edu (Terry Lambert)
To:        pritc003@maroon.tc.umn.edu (Mike Pritchard)
Cc:        ache@astral.msk.su (Andrey A. Chernov Black Mage), hackers@FreeBSD.org, sos@login.dknet.dk
Subject:   Re: Screen print capability
Message-ID:  <9504302346.AA04405@cs.weber.edu>
In-Reply-To: <199504300643.BAA05486@mpp.com> from "Mike Pritchard" at Apr 30, 95 01:43:49 am

next in thread | previous in thread | raw e-mail | index | archive | help
> Are you saying that SCO consoles allow some type of escape sequence
> to be output to the screen to print the screen?  Trivial to add
> to my current code, but I'm not sure I like the idea, since if I 
> accidently cat a binary I might wind up doing 20 screen prints,
> or someone might send me a mail-bomb with 20 of those escape sequences
> in it.

No, what the console can do is take an escape sequence and as a result,
report the screen contents as if they were being typed at the
keyboard, spacing, color, and all.

This is not terrifically useful for screen-print unless the app sending
the escape is the only one that will be posting a read to the console.

An alternative to this is the ioctl() interface, that causes the
screen contents to be reported into a user buffer instead.

> Even if the screen contents are returned via an ioctl instead
> of a read, you still need some mechanisim to wait for a screen print
> event (screend, and I'll pick another name) and then suck up the contents 
> and print them out.

The main magic here is needing a way to bind a key to a user space instead
of a kernel action.  One way of achieving this would be to call an ioctl()
that eats a particular key sequenc and returns only when it has been
seen.

Then your print screen program becomes an ioctl() to get the print
key followed by an ioctl() to get the screen contents, plus whatever
code you want to use to do with the contents what you will.

Then loop back to the first ioctl().

> Are there any SCO applications
> that we really want to support that rely on a screen capture mechanisim
> that works in a certain way?  If so, then I'll be glad to do things
> that way if someone would just tell me what the external interface
> needs to look like.

I believe Microsoft BASIC does, as does the partial-hardware 3270
emulator available from a third party.


					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?9504302346.AA04405>