🚀 go-pugleaf

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 --*--

Hmmm.. maybe we can ask the NXFax people how they do it. Don't they have to
get around this also? I think that you can have the fax on one machine
and then initiate the fax from a different machine on the network. But, then
again, I may be totally wrong here :) I know they had to do something so that
you can fax stuff without making your window server public, though. Maybe
they are related.

Alvin Jee
alvin@cse.ucsc.edu

wiml@milton.u.washington.edu (William Lewis) writes:

>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?"

[...lot's of bootstrap port nastiness deleted...]

Under 3.0, all children of lpd have WindowServer access.  In case your
program is not a "natural" child of lpd, you can have it started at
boot time by  /usr/lib/NextPrinter/lpd.children.  

Marcel