Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!hanami!landman
From: landman%hanami@Sun.COM (Howard A. Landman)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Something HyperCard *OUGHT* to do
Message-ID: <51140@sun.uucp>
Date: 28 Apr 88 00:39:38 GMT
References: <50949@sun.uucp> <27980@yale-celray.yale.UUCP>
Sender: news@sun.uucp
Reply-To: landman@sun.UUCP (Howard A. Landman)
Distribution: comp
Organization: Sun Microsystems, Mountain View
Lines: 28

In article <27980@yale-celray.yale.UUCP> jellinghaus-robert@yale.UUCP writes:
>You're way behind Apple.  What you're describing is called IPC (for
>Inter-Process Communication), and Apple has been working on it for a
>while now.

Unless Apple uses IPC to mean something completely different from what
it means in the UNIX world, it is only slightly related to what I
proposed.  IPC is a useful *underlying* capability which is normally
accessed through system calls in compiled programs.  I'm proposing an 
*overlying* (i.e., directly visible to every user) capability that would
be accessed through HyperTalk.

The closest equivalent to the problem that I've seen in the non-graphics 
UNIX world is that some programs check to see whether their input is
really a terminal.  Such programs may refuse to run if their input is
redirected from a file or pipe.  This once made it extremely painful to do
things like write an automatic rogue-playing program.  When pseudo-ttys
and rsh became available, the problem vanished, because you could
run your program under an rsh and pipe into that.

Will Apple's IPC allow you (for example) to control a program that throws
up a modal dialog?  If not, it isn't powerful enough to replace what I
proposed.  Will it require the user to make system calls?  If so, it's
too low-level for most people.

	Howard A. Landman
	landman@hanami.sun.com
	UUCP: sun!hanami!landman