Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!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: <51578@sun.uucp>
Date: 2 May 88 18:59:47 GMT
References: <50949@sun.uucp> <1488@csib.csi.UUCP>
Sender: news@sun.uucp
Reply-To: landman@sun.UUCP (Howard A. Landman)
Distribution: comp
Organization: Sun Microsystems, Mountain View
Lines: 79

In article <1488@csib.csi.UUCP> jwhitnel@csib.UUCP (Jerry Whitnell) writes:
>Actually, the input side is not that difficult.  One could write extensions
>to hyperard that would drive the input side of another program by feeding
>events to it.  There are a few problems involved like finding the partition
>holding the program and getting the events in the queue, but nothing a
>good hacker couldn't figure out.

I'm proposing a more limited ability in a sense.  All I desire is that
HyperCard be able to communicate with a program that has been opened
*under* HyperCard, so finding it is not a problem (for the user).

>The real problem is the output side of the program.  The reason pipes
>work so well in UNIX is that all output from a program is a stream of
>bytes, usually text, that can be passed around at will.  However the
>output of a Mac program is much more complicated and includes not
>only text but also graphics of all sorts.

Actually this isn't entirely true - consider a UNIX program that has a
full-screen interface.  In theory, any program could interpret the
bytestream, but that essentially means writing a complete terminal
emulation package inside your program.  You'd really prefer to be able
to query certain screen locations; sort of "curses" in reverse.  The Mac's
graphics capability does make things more complicated than that, but even
just being able to query pixel values would provide some help.  Even better
would be routines that could be given a font, style, and screen location,
and return the text there (I know this is harder, but I don't think it's
impossible).

>In your example of Go programs, Dragon doesn't keep a text list of its
>moves, it only draws them on the board using (I assume) FillOval.

Actually it also prints the move in alphabetic ("Korschelt") notation,
but for programs in general you can't count on that.

>For a Hypercard script to drive two programs
>playing each other, it would have to recognize the FillOval command, detirmine
>from the rectangle and color which side moved and where the move was and then
>generate the equivalent muse movements to pass the move to the other program.

Well, not necessarily recognize FillOval, although having some way to
trap certain calls by the slave program would certainly be useful to
the serious programmer.  It would be possible to figure out what had
happened from examining screen (or window) pixels.  While this would be
somewhat slow, in my case it would be adequate since the programs
themselves are rather slow (couple of minutes per move).

>(BTW, try to get two UNIX go programs to play each other.  Not as easy as
>one might hope for :-).

Too true.  It would be nice if everyone conformed to some kind of
standard protocol (like the USENIX protocol, but with more features)
which allowed Go programs to be piped together.

>the Hypercard application, but then you'd have to reverse engineer each
>program to see how it generated each of its displays, so that your program
>can read it and respond in the appropiate fashion.  Hypercard applications
>can be written to support this, however.

Exactly.  I'm willing to do the reverse engineering work, because it's
much less than the manual work of running the programs by hand; but
right now, I don't have the choice,

>I've heard that Tempo II also has a programming interface that could
>be used for this purpose.

I'll be checking into Tempo II for the "playing out partial games"
driver.  I'll report back when I know whether it can handle that.
The tricky part will probably be recognizing that the game has ended.

>The general idea has existed for awhile (Andy Hertzfeld wanted to put
>something like it in Servent, but I think Servant is dead), but your
>the first to suggest using HyperCard as the driver.

This is a natural suggestion because HyperTalk already has syntax for
many of the things you want to do.  It's also very widely understood
and used.

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