Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!milton!wjs
From: wjs@milton.u.washington.edu (William Jon Shipley)
Newsgroups: comp.sys.next
Subject: Re: Possible to open remote windows?
Message-ID: <19083@milton.u.washington.edu>
Date: 27 Mar 91 01:04:42 GMT
References: <1991Mar24.231657.21573@cs.ubc.ca>
Organization: University of Washington, Seattle
Lines: 48

Stuart Ritchie writes:
>Hello again netters, first I must extend my thanks to William
>Shipley for his swift and helpful answer to my "hit test"
>question a week or so back.
Aw, shucks.

>This time I wondering if it's possible to open windows on remote
>machines.  No, I don't mean the -NXHost stuff.  What I'm thinking
>about is having a program run on my machine, let me interact with
>it locally (via windows, duh) and also open windows on other
>machines.  Sort of like -NXHosting individual windows of an
>application.
>
>I suppose I could use the client/server model, but that would
>involve at least two separate applications.  I want one app
>to display and receive events from many machines.

I played with doing this a while ago when developing a multi-user game.
My first thought was to open multiple connections to different window
servers on different machines, using DPSCreateContext.  The problem with
this is that apparently there is a global in the NXApp object that tells
the AppKit which context to write to, so you'd have to do a bunch of kludging
to get the AppKit to write to any connection other than your main connection
(to your machine).  (I never bothered trying this.)

The other solution, which worked, is to start up a program and then BEFORE
YOUR NXApp OBJECT INITS declare some shared memory and fork off a bunch of
copies of your program, each of which has the NXHost preference set to a
different machine.  Then start up NXApp in each of the forked copies.

This works.  You get a bunch of NXHosted programs appearing on different
machines, which have a nice area of shared memory to speak in.  You can even
kludge this a bit by declaring the memory as a zone before using it, so
that you can allocate new objects in this zone.

The problem with this approach is that you must decide how much memory to
allocate before you fork.

Note that another intuitive approach would be to just have mulitple NXApps in
different threads in the same task.  No dice, the AppKit expects one and only
one NXApp.  Kinda bummin, that.

BTW, the method I ended up using was none of these: I simply have as many
copies of my program running as I have users, and trap all messages any user
sends, copying the message and sending it to all the other programs.  This
works nicely for a well-defined set of inputs.

-william shipley