🚀 go-pugleaf

I've accumulated 5 unrelated X questions, and I'd be very appreciative of
any help. The first three are administrative, the last two are more real.
Sorry there's so many!

1) I've seen hints going by that X source might be available for anonymous
   ftp from a computer named 'zap.mit.edu'.  That machine is not in any
   host table that I can find, nor do I have access to any machine that
   understands domain routing. Can someone provide me with the internet
   *number* for 'zap' ?

2) The newsgroup 'comp.window.x' just appeared, without announcement, on our
   local news machine. I can't quite tell - is this newsgroup fed by the 
   'xpert' and 'xport' mailing lists? If so, I'll go ahead and unsubscribe 
   to the mail...

3) I need my software to be portable to various X's, but I find myself
   having to do things in the X driver which are BSD-specific. I don't
   know: is this unsafe or does X perhaps *only* exist on BSD machines?

4) I'm running X on Ultrix/GPX's. It's V10; I can't tell which release. I'm
   putting up graphics windows from a process, and I would like keystroke
   events that occur in my windows to appear as keystrokes in the xterm
   window that originally started the process. So I thought, "Ahah!, I'll just
   use the xterm window as the *owner* of my graphics windows when I create
   them." 

   Unfortunately, when I do this (don't ask how I discover which is the
   right xterm window :-), Bad Things happen. When I call XMapWindow on the 
   new window: A) the xterm window shrinks to 1/4 its original size, and 
   B) it starts flickering violently. 

   Does anyone know how I can do what I want? For example, is there a way
   to propagate events from one window to another? (I assume XPutBackEvent
   is purely process-local, and wouldn't appreciate me munging the window
   descriptor anyhow.) No, I don't want to Focus because my users will be 
   totally mystified about what's going on...

5) Lastly, my graphics are running as a utility called from a user-written
   application. I do not have complete control over when I do and do not
   wait for events. If a medium-to-long time elapses between the times that
   I can dequeue events, X will choke - I assume because it thinks it has
   "too many". To fix this problem, short of munging X, I assume I should 
   arrange to get *interrupts* as the events occur. SIGALRM's are not 
   suitable because the user program may easily trash them.

   So: the XPending manual entry makes a cryptic reference to "call XPending 
   before doing a select(2) on the file descriptor contained in the display 
   structure."  One of the interesting things I can think of doing with "the
   file descriptor" is maybe to enable the SIGIO interrupt on it - SIGIO is
   less used by users than SIGALRM, and it's also more precise. Does anyone 
   have any details?

thanks much for reading all this -

garry wiegand   (garry%oak.cadif.cornell.edu@cu-arpa.cs.cornell.edu)