home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.next.misc:22141 comp.sys.next.programmer:7313
- Newsgroups: comp.sys.next.misc,comp.sys.next.programmer
- 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
- From: wiml@milton.u.washington.edu (William Lewis)
- Subject: Re: WindowServer connections
- Message-ID: <1992Nov19.192443.25474@u.washington.edu>
- Sender: news@u.washington.edu (USENET News System)
- Organization: University of Washington, Seattle
- References: <1992Nov10.010325.4556@jhunix.hcf.jhu.edu>
- Date: Thu, 19 Nov 1992 19:24:43 GMT
- Lines: 76
-
- In article <1992Nov10.010325.4556@jhunix.hcf.jhu.edu> you write:
- >Its been asked many times how one opens a connection to the WindowServer
- >when no one is logged in ( by myself at least three times ). Everytime
- >I get no useful answer, just a lot of questions of the form "Why would you
- >want to do that?"
-
- Well, I was about to answer, "You can just obtain the loginwindow's
- or window server's bootstrap port and look up the WindowServer service,
- as long as your program is running as root", but it seems this won't
- work. The WindowServer port gets placed in the bootstrap service
- of all tasks descended from the loginwindow, but it does this by
- making a subset port and installing the service *after* login and
- password verification! In fact, the sequence of events is as follows:
-
- WindowServer starts up. Upon startup, the window server port is *always*
- advertised (in effect, public window server is always on.)
-
- Loginwindow is started (from /etc/ttys, I think.) Loginwindow looks up
- the window server port once a second or so until it finds it (in case
- it starts up before WindowServer). After connecting, it sends a
- "false setpubliclistener" (I think that's the command). This causes
- the WS to stop advertising its port on the network name server.
-
- Loginwindow loads the windowPackage and so forth, puts up the panel,
- and waits for input.
-
- When a user logs in, the loginwindow uses the "setbootstrapport" PostScript
- primitive (also undocumented =8) ) to cause the window server to install
- its port in the bootstrap service. I think the WS creates a subset bootstrap
- port at some point also.
-
- Then loginwindow does the loginhooks and spawns the Workspace. I didn't
- examine this part very closely.
-
-
- Anyway, the upshot of this is that you can't just extract the correct port
- from the window server, at least not until someone's already been verified
- and is in the process of logging in. (Don't ask me why NeXT didn't take
- the more obvious, much more secure (no little public-window-server
- windows-of-opportunity) and IMHO more elegant route of simply using the
- bootstrap service the way it seems to have been designed.) However,
- I think there are still a few ways to do w3hat you want, although I
- haven't actually tried them:
-
- -- You could put a "wrapper" around the Loginwindow program that would
- sit around until it found the window server port, squirrel it away
- somewhere, and then exec the real loginwindow.
-
- -- You could try to grab the window server port from the network name
- server in the little gap after the WS had advertised it but before loginwindow
- has told the WS to unadvertise it.
-
- -- You could do some seriously ugly port peeking, looking for a port
- that's accessible to both the loginwindow; loginwindow would have send rights
- and the WS would have receive rights. I don't know if there's only oe such
- port.
-
- In any case, once you had the port rights, it would be a relatively simple
- matter to trick your application into using them for its window server
- connection. Since loginwindow seems to use normal appkit-style window server
- interaction, it should be possible to run any appkit program like this
- (as long as it didn't try to talk to the workspace, the pasteboard, etc.)
-
-
- (P.S. to NeXT: How come the user level processes never get a privileged
- bootstrap port?!? Having a subset port that encompasses just the current
- user session (console or otherwise) would be the perfect answer to
- all those times when two tasks need to share a port but don't really want
- to advertise it on the network. What's the point of running on top of a
- cool OS like Mach if you can't use the features?)
-
- --
- email: wiml@u.washington.edu | Home: Seattle, Washington |
- (William Lewis) | 47 41' 15" N 122 42' 58" W |
- NeXTmail: wiml@ingalls.cs.washington.edu `-------------------------------'
- --*-- Member, Coalition to Preserve Semantic Vacuity --*--
-