markm@mcrware.UUCP (Mark Millard) (08/29/90)
I have a few questions concerning the usage of Chuck McManis's "raw"
and "cooked" utilities (recently re-posted).
I was wondering if it is possible to combine the raw mode with
waiting for signals on stdin's message port. I modified Chuck's
testraw program to do the following:
void main()
{
struct FileHandle *stdin_fh;
struct UFB *stdin_ufb;
struct MsgPort *readport;
ULONG signals,readsig;
/* get message port for stdin */
stdin_ufb = (struct UFB *) chkufb(fileno(stdin));
stdin_fh = (struct FileHandle *) (stdin_ufb->ufbfh);
readport = ((struct FileHandle *) (BADDR(stdin_fh)))->fh_Type;
/* set stdin to CBREAK mode */
if (raw(stdin) != 0) perror("raw");
/* gather and dispatch input */
readsig = 1 << readport->mp_SigBit;
signals = Wait(readsig);
if (signals & readsig) {
/* read input here */
}
/* reset stdin back to normal */
if (cooked(stdin) != 0) perror("raw");
}
What happens is that "Wait" never returns. Is the signal valid in raw
mode? If I replace the "gather and dispatch input" segment with
infh = Input();
ok = WaitForChar(infh,1000000);
if (ok)
read(fileno(stdin),buffer,1);
It seems to work fine. However, this is not what I want since eventually
I want to wait for input from other sources (i.e. intuition windows).
How can I do this? Is there something similar to UNIX's "select()"
mechanism which somebody can help me with?
My second question concerns Chuck's testraw program and using "fputc()"
or "putc()". I modified his while loop to be
while ((c = fgetc(win)) != 'Q') {
i = (i + 1) % 25;
if (i == 0 ) fputc('\n',win);
fputc(c,win);
}
"fputc" put it somewhere, but not in the console device. The same was
true with "putc". Has anybody else tried this?
Thanks for any help you can provide.
Mark Millard
Microware Systems Corp.
email: sun!mcrware!markm
phone: (515)-294-1929dillon@overload.Berkeley.CA.US (Matthew Dillon) (09/05/90)
In article <2570@mcrware.UUCP> markm@mcrware.UUCP (Mark Millard) writes: > >I have a few questions concerning the usage of Chuck McManis's "raw" >and "cooked" utilities (recently re-posted). > >I was wondering if it is possible to combine the raw mode with >waiting for signals on stdin's message port. I modified Chuck's >testraw program to do the following: No, all DOS calls are synchronous. DOS will never initiate an asynchronous packet to a process's message port and thus will never set any signal of its own accord. You must >What happens is that "Wait" never returns. Is the signal valid in raw >mode? If I replace the "gather and dispatch input" segment with > infh = Input(); > ok = WaitForChar(infh,1000000); Use WaitForChar(). Alternately, you can manually construct and send a READ request to the console handler and construct a replyport for that request, in which case you get the reply when data is ready. The downside to this is that there is no way to *abort* the request... you *must* wait for the request to be fullfilled. So WaitForChar() is the only supported way of 'polling' the console. Commodore definitely needs some kind of support for asynchronous abortable requests. >Mark Millard >Microware Systems Corp. >email: sun!mcrware!markm >phone: (515)-294-1929 -- -Matt Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
jesup@cbmvax.commodore.com (Randell Jesup) (09/15/90)
In article <dillon.5758@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > Use WaitForChar(). Alternately, you can manually construct and send > a READ request to the console handler and construct a replyport for > that request, in which case you get the reply when data is ready. The > downside to this is that there is no way to *abort* the request... you > *must* wait for the request to be fullfilled. So WaitForChar() is the > only supported way of 'polling' the console. Well, I believe the con: device aborts a read request if you attempt to close the filehandle - I think it may even be documented somewhere, but I haven't checked and the memory is vague. In order for this to work, the read request would have had to have been sent asynchronously and with a separate port for it to return to. > Commodore definitely needs some kind of support for asynchronous > abortable requests. Yes. You'll note that Asynch packets are now supported in 2.0, and I hope to get a working AbortPkt into a future version - right now it's a NOP. Unfortunately, it's not so easy to do retroactively - a lot of our design options are limited by compatibility issues. > Matthew Dillon dillon@Overload.Berkeley.CA.US -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"