akm@spencer.cs.uoregon.edu (Anant Kartik Mithal) (08/04/90)
Hi, As part of my research I have to write a bunch of applications that can talk to each other. They *have* to be seperate applications (I can't write one huge application that has a bunch of modules that can share data. In various OS courses, this has been described as Inter process communication. I haven't found *any* reference to this in any of the Apple/Apple Press things I've read, nor in (say) the Think C/Think Pascal documentation. The only reference I got was in the Tech Notes stack, where I was essentially told: Wait for System 7. Has anyone done anything which involved one application talking to another? Could I set up an init that applications could communicate with, and leave messages for each other? IPC (or IAC, inter application communication, as Apple calls it), is available in lots of other interfaces like Sun Views, X Windows, and even in Microsoft Windows.... any help would be much appreciated. kartik ----------------------------------------------------------------------------- Anant Kartik Mithal akm@cs.uoregon.edu Department of Computer Science akm@oregon.BITNET University of Oregon
robert@polari.UUCP (robert) (08/05/90)
> As part of my research I have to write a bunch of applications that > can talk to each other ... I haven't found *any* reference to this > ... I was essentially told: Wait for System 7. There were several articles in MacTutor written by Frank Alviani and Paul Snively on implementing an IAC driver on the Mac. The articles were: 1) 8/88 "Protocols for an IAC Driver, Part 1" Alviani & Snively; MacTutor vol 4, no. 8 2) 10/88 "IAC Driver, Part 2" Alviani & Snively; MacTutor vol 4, no. 10 3) 11/88 "IAC Driver Demo in MPW C" Alviani; MacTutor vol 4, no. 11 You also might want to check out: 4) 8/89 "Apples IAC in System 7" Alviani; MacTutor vol. 5, no. 8 5) "7.0 Camplatibility Cookbook" John Harvey, MacDTS, Apple Computers (released to certified developers with the Alpha version of System 7.0. Requires "Viewer" - on alpha CD) 6) "Inside Mac, Volume 6" Apple Comupters (released to certified developers with the Alpha version of System 7.0 as a Hypercard stack) You can get back issues of MacTutor and source code on disk from MacTutor at the address given below. MacTutor also sells collections of articles for each year. The 1988 collection should contain articles 1), 2), and 3). It costs around $30 from MacTutor. Back issues are around $3 each for 1988, source code disk are about $8 each. MacTutor 1250 N. Lakeview, Ste. O Anaheim, CA 92807 (714) 777-1255 |***********************************************************************| |Robert Riebman | robert@polari | |Northwest Information Technology |(...uw-beaver\!sumax\!polari\!robert)| |P.O. Box 3156 | | |Redmond, WA 98073 | "Hack and Enjoy" | |***********************************************************************|
jackiw@cs.swarthmore.edu (Nick Jackiw) (08/05/90)
robert@polari.UUCP (robert) writes:
.>
.> > As part of my research I have to write a bunch of applications that
.> > can talk to each other ... I haven't found *any* reference to this
.> > ... I was essentially told: Wait for System 7.
.>
.> There were several articles in MacTutor written by Frank Alviani and
.> Paul Snively on implementing an IAC driver on the Mac.
.>
[MacTutor references deleted]
.>
.> You also might want to check out:
.>
[Wait for System 7 references deleted]
The MacTutor stuff, which is excellent, is probably more general than you
need, if your suite of programs require only a rigidly specified communication
protocol. Its worth reading anyway, if you're thinking of a driver-based
IPC.
You may also want to consider doing it with Appletalk. An oft-overlooked
an oft-overlooked feature of Appletalk is that it works fine even if you
aren't connected to a net: each program can request a socket on the same
machine, and then communicate with others (also on that machine) through
that socket.
Neither of these schemes has System 7-IPC's advantage of having a nicely
developed protocol for IPC between applications of which only one is
currently running. Whether this feature is relevant to your application
is up to you, of course.
feature of A
--
------------------------
Nick Jackiw jackiw@cs.swarthmore.edu "Every minute of the future
Visual Geometry Project jackiw@swarthmr.bitnet is a memory of the past."
Swarthmore College, PA 19081-1397 -Laivachml10+@andrew.cmu.edu (Michael A. Libes) (08/06/90)
Most developers overlook the simple mechanism of shared memory. Since the Mac doesn't have protected memory spaces, it is very simple to create a shared memory system between applications. It will be a long time until the apps break due to protected memory... ------------------------------------------------------------------ Lunarmobiscuit (Luni) Internet Address: MacMach Project ml10@andrew.cmu.edu Carnegie Mellon University ------------------------------------------------------------------
minow@mountn.dec.com (Martin Minow) (08/06/90)
>robert@polari.UUCP (robert) writes: > As part of my research I have to write a bunch of applications that > can talk to each other ... I haven't found *any* reference to this > ... I was essentially told: Wait for System 7. To repeat what Nick Jackiw wrote, you might be able to solve your problem using Appletalk. About two years ago, I wrote a distributed application (three computers for data, two managed dedicated projection displays) that used Appletalk to pass data around. To debug it on my single home machine, I used the SetSelfSend capability and (wonder of wonders) it worked perfectly the first time I tried to talk between two machines. A few minor tricks that made my life easier: -- The "server" and "client" were the same application (a menu option selected "server," "client," or "both"). -- All of the Appletalk requests were asychronous. -- The event loop polled the Appletalk queue for completed (and new) messages, putting them back on the free list when done. -- I could turn on a *lot* of debug tracing. The hardest part of the problem was handling the name-binding protocol -- the description is obscure (to put it politely). Be sure to read the relevant tech-notes. Martin Minow minow@bolt.enet.dec.com
chewy@apple.com (Paul Snively) (08/07/90)
In article <JMLN7T@cs.swarthmore.edu> jackiw@cs.swarthmore.edu (Nick Jackiw) writes: > .> There were several articles in MacTutor written by Frank Alviani and > .> Paul Snively on implementing an IAC driver on the Mac. ... > The MacTutor stuff, which is excellent... Thank you--I wish I could look back at that work and say the same thing! ;-) >... is probably more general than you > need, if your suite of programs require only a rigidly specified communication > protocol. Huh? The IPC driver in MacTutor doesn't deal with "protocol" at all; it just lets you poll to see if the data (which can be in any format you like; it's just a block of bytes) has changed since the last time you checked. It's more like the Edition Manager than any of Apple's IAC protocols. > Its worth reading anyway, if you're thinking of a driver-based IPC. This I'll agree with, and I'll even go so far as to ask what other kind of IPC makes sense on the Macintosh? > You may also want to consider doing it with Appletalk. An oft-overlooked > an oft-overlooked feature of Appletalk is that it works fine even if you > aren't connected to a net: each program can request a socket on the same > machine, and then communicate with others (also on that machine) through > that socket. Frank and I originally intended to rewrite the SAWS (Snively, Alviani, Welsh, Sheets) IPC driver in terms of AppleTalk precisely so that we would have a network-capable IPC system. Your point is well taken. > Neither of these schemes has System 7-IPC's advantage of having a nicely > developed protocol for IPC between applications of which only one is > currently running. Unfortunately, neither does System 7.0's IAC suite; "store and forward" messages didn't make it in. [sigh] __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
RESHEF1@BGUVM.BITNET (Eran Reshef) (08/07/90)
There isn't an IPC on the Mac yet, but here is a quick and dirty approach
(I never tried it, but I don't think it shouldn't work):
Use the system resource file, which is common for all the application, as a
place to leave messages. Define a resource type which will hold the messages.
Each app will check this resource type in its main event loop. If it finds
any, it will check it, decide whether it belongs to itself and if it does
remove it & handle it.
To post a message, AddResource of the known type to the system file.
The resource should be something like:
msg = record
from : Str255; { the name of the sender }
to : Str255; { the name of the recipient}
message: Str255;
end;
I hope this helps.
-------
Eran Reshef,
Micro Department, Computation Center,
Ben-Gurion University of the Negev,
Beer - Sheva, Israel.
Bitnet : RESHEF1@BGUVM.BITNET
"Vanity of vanities, all is vanity"jackiw@cs.swarthmore.edu (Nick Jackiw) (08/08/90)
chewy@apple.com (Paul Snively) writes: > In article <JMLN7T@cs.swarthmore.edu> jackiw@cs.swarthmore.edu (Nick > Jackiw) writes: > > The MacTutor stuff, which is excellent... > >... is probably more general than you > > need, if your suite of programs require only a rigidly specified > > protocol. > > Huh? The IPC driver in MacTutor doesn't deal with "protocol" at all; it > just lets you poll to see if the data (which can be in any format you > like; it's just a block of bytes) has changed since the last time you > checked. It's more like the Edition Manager than any of Apple's IAC > protocols. Wrong. Protocol means code (in the non-programmer's sense of the word). Any set of routines is governed by a protocol. Determining whether data have changed, registering and querying about existing data types, and other features of your driver may be unnecessary in a given IPC situation. They are all necessary in the *general* IPC scenario, as I stated. > > > Its worth reading anyway, if you're thinking of a driver-based IPC. > > This I'll agree with, and I'll even go so far as to ask what other kind of > IPC makes sense on the Macintosh? Are you serious? Any cdev which communicates with an active INIT is doing IPC, usually by accessing common storage in the system heap. Any program which launches another program with a customized AppFile record is doing IPC. (Remember MDS's integrated-but-separate editor, linker, and compiler?) If your requirements aren't too serious, you could even do IPC by means of the global deskscrap. > > Neither of these schemes has System 7-IPC's advantage of having a nicely > > developed protocol for IPC between applications of which only one is > > currently running. > > Unfortunately, neither does System 7.0's IAC suite; "store and forward" > messages didn't make it in. [sigh] Ouch. > Paul Snively -- -----Nick Jackiw [jackiw@cs.swarthmore.edu|jackiw@swarthmr.bitnet------ "This orbe of starres fixed infinitely vp extendeth hitself in altitvde sphericallye, and therefore immovable the pallace of foelicity garnished with perpetvall shining glorious lightes innvmerable." - Thomas Digges
chewy@apple.com (Paul Snively) (08/08/90)
In article <4KPN20@cs.swarthmore.edu> jackiw@cs.swarthmore.edu (Nick Jackiw) writes: > Protocol means code (in the non-programmer's sense of the word). > Any set of routines is governed by a protocol. Determining whether > data have changed, registering and querying about existing data types, > and other features of your driver may be unnecessary in a given IPC > situation. They are all necessary in the *general* IPC scenario, as I > stated. I see. My definition of "protocol" is "some means of communicating that is independent of the transport." The only "protocol" (by this definition) that Frank and I did was our simplistic versioning stuff. However, your point is well taken. > > This I'll agree with, and I'll even go so far as to ask what other kind of > > IPC makes sense on the Macintosh? > > Are you serious? Any cdev which communicates with an active INIT is doing > IPC, usually by accessing common storage in the system heap. Any program > which launches another program with a customized AppFile record is doing > IPC. (Remember MDS's integrated-but-separate editor, linker, and compiler?) > If your requirements aren't too serious, you could even do IPC by means > of the global deskscrap. All true, but cdev/INIT communication by heap-searching is a dangerous hack. The AppParmHandle example isn't a generalized IPC scheme, and the global deskscrap is _supposed_ to be "owned" by the user, with no software providing any surprises. What I meant by "makes sense" was a combination of architectural cleanliness combined with practicality. > > > Neither of these schemes has System 7-IPC's advantage of having a nicely > > > developed protocol for IPC between applications of which only one is > > > currently running. > > > > Unfortunately, neither does System 7.0's IAC suite; "store and forward" > > messages didn't make it in. [sigh] > > Ouch. I'll say. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________