Multi-standalone communication

Dar Scott dsc at
Thu Dec 7 17:30:09 EST 2006

On Dec 7, 2006, at 1:26 PM, Richard Gaskin wrote:

> Richard Miller wrote:
>> The computer in question is not set up with networking.
> I'm not sure if UDP on the same machine is prevented even without  
> external networking enabled.  Maybe someone here can explain.

Well, that had been the case, but I don't remember if I have tried  
that on XP.  An imaginary LAN is a workaround, but that sounds like  
too much for Richard.  Maybe not, but it does involve selecting it as  
an adaptor and installing the adaptor.  I guess setting up a rev chat  
server might be tried to check these questions.  That might also give  
the clues needed to implement the comm.

I have wondered about named pipes.  On Windows, they are not  
symmetrical and the creating end has to do something special.  I  
think it might be possible with some sort of \\ file name to open the  
other end.  The creation end might be made by some special command- 
line tool (Ken?) which is controlled by process I/O.

Those with a weak heart should not read this paragraph.  Maybe the  
registry can be used for communication.

Process I/O can be possible for inter-rev-app comm under some  
circumstances.  One standalone is the controlling app.  The others  
are started and ended by the controlling app.  All communication is  
to/from/through the controlling app.  There are some gotchas in  
process I/O and in using stdin/stdout, but this discussion list is  
here.  (The more general approach might be a tree including a chain.)

It might be possible to share a file if one is open for read and the  
other is open for write.  Comm is then done in the buffers.  I don't  
think this can be done with Rev, but it might be worth the experiment.

Renaming files or folders will still involve file I/O, but it might  
minimize that.

I have seen virtual loopback serial drivers.  That might mean buying  
something.  Serial send blocks, but that might be for a very short  
time in this case.

One can lock a resource (say, open a serial port) and unlock it and  
send messages by Morse code.

<vaporware>I have tinkered with a more general send.</vaporware>

Get an external made.

Put a 1X1 pixel system window in the corner of the screen.  Change  
the color.  The other stack can take a snapshot of that and see what  
the color is.  You can then have 4 senders and lots of receivers.

I would still lean toward UDP (or TCP) or files or file names.


More information about the Use-livecode mailing list