home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / next / misc / 22141 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  4.4 KB

  1. Xref: sparky comp.sys.next.misc:22141 comp.sys.next.programmer:7313
  2. Newsgroups: comp.sys.next.misc,comp.sys.next.programmer
  3. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!usenet.coe.montana.edu!news.u.washington.edu!milton.u.washington.edu!wiml
  4. From: wiml@milton.u.washington.edu (William Lewis)
  5. Subject: Re: WindowServer connections
  6. Message-ID: <1992Nov19.192443.25474@u.washington.edu>
  7. Sender: news@u.washington.edu (USENET News System)
  8. Organization: University of Washington, Seattle
  9. References: <1992Nov10.010325.4556@jhunix.hcf.jhu.edu>
  10. Date: Thu, 19 Nov 1992 19:24:43 GMT
  11. Lines: 76
  12.  
  13. In article <1992Nov10.010325.4556@jhunix.hcf.jhu.edu> you write:
  14. >Its been asked many times how one opens a connection to the WindowServer
  15. >when no one is logged in ( by myself at least three times ).  Everytime
  16. >I get no useful answer, just a lot of questions of the form "Why would you
  17. >want to do that?"
  18.  
  19.    Well, I was about to answer, "You can just obtain the loginwindow's
  20. or window server's bootstrap port and look up the WindowServer service,
  21. as long as your program is running as root", but it seems this won't
  22. work. The WindowServer port gets placed in the bootstrap service 
  23. of all tasks descended from the loginwindow, but it does this by
  24. making a subset port and installing the service *after* login and
  25. password verification! In fact, the sequence of events is as follows:
  26.  
  27. WindowServer starts up. Upon startup, the window server port is *always*
  28. advertised (in effect, public window server is always on.)
  29.  
  30. Loginwindow is started (from /etc/ttys, I think.) Loginwindow looks up
  31. the window server port once a second or so until it finds it (in case
  32. it starts up before WindowServer). After connecting, it sends a 
  33. "false setpubliclistener" (I think that's the command). This causes
  34. the WS to stop advertising its port on the network name server.
  35.  
  36. Loginwindow loads the windowPackage and so forth, puts up the panel,
  37. and waits for input.
  38.  
  39. When a user logs in, the loginwindow uses the "setbootstrapport" PostScript
  40. primitive (also undocumented =8) ) to cause the window server to install
  41. its port in the bootstrap service. I think the WS creates a subset bootstrap
  42. port at some point also.
  43.  
  44. Then loginwindow does the loginhooks and spawns the Workspace. I didn't 
  45. examine this part very closely.
  46.  
  47.  
  48.   Anyway, the upshot of this is that you can't just extract the correct port
  49. from the window server, at least not until someone's already been verified
  50. and is in the process of logging in. (Don't ask me why NeXT didn't take
  51. the more obvious, much more secure (no little public-window-server
  52. windows-of-opportunity) and IMHO more elegant route of simply using the
  53. bootstrap service the way it seems to have been designed.) However,
  54. I think there are still a few ways to do w3hat you want, although I
  55. haven't actually tried them:
  56.  
  57.   -- You could put a "wrapper" around the Loginwindow program that would
  58. sit around until it found the window server port, squirrel it away
  59. somewhere, and then exec the real loginwindow.
  60.  
  61.   -- You could try to grab the window server port from the network name
  62. server in the little gap after the WS had advertised it but before loginwindow
  63. has told the WS to unadvertise it. 
  64.  
  65.   -- You could do some seriously ugly port peeking, looking for a port 
  66. that's accessible to both the loginwindow; loginwindow would have send rights
  67. and the WS would have receive rights. I don't know if there's only oe such
  68. port.
  69.  
  70.   In any case, once you had the port rights, it would be a relatively simple
  71. matter to trick your application into using them for its window server 
  72. connection. Since loginwindow seems to use normal appkit-style window server 
  73. interaction, it should be possible to run any appkit program like this 
  74. (as long as it didn't try to talk to the workspace, the pasteboard, etc.) 
  75.  
  76.  
  77. (P.S. to NeXT: How come the user level processes never get a privileged
  78. bootstrap port?!? Having a subset port that encompasses just the current
  79. user session (console or otherwise) would be the perfect answer to 
  80. all those times when two tasks need to share a port but don't really want
  81. to advertise it on the network. What's the point of running on top of a 
  82. cool OS like Mach if you can't use the features?)
  83.  
  84. -- 
  85. email: wiml@u.washington.edu             |  Home:  Seattle, Washington   |
  86.      (William Lewis)                     |  47 41' 15" N   122 42' 58" W | 
  87. NeXTmail: wiml@ingalls.cs.washington.edu `-------------------------------'
  88.         --*-- Member, Coalition to Preserve Semantic Vacuity --*--
  89.