A communication protocol for GEM applications XAcc
The XAcc protocol was originally designed for non-multitasking
versions of GEM to allow data exchange between the main application
and any number of accessories. Since the AES did not provide a
function to find the application IDs (apid's) of other applications
without knowing their names, XAcc had to rely on the undocumented
feature that the main application always has the apid 0. Therefore
XAcc in its present (1) form does not work in a multitasking
environment. However, AES 4.0 provides the new function appl_search(),
which allows any application to find the apids of all other
applications running concurrently. This makes it possible to design a
modified XAcc that does not use any 'dirty tricks'. This document
contains a proposal for such a modified XAcc; the changes with respect
to the previous definition are small and modifying an existing
XAcc-based application should be a matter of minutes. Since
single-tasking TOS will still be with us for a while, applications are
encouraged to implement both 'traditional' and 'modern' XAcc,
depending on the version number of the AES.
The GEM AES functions appl_write() and appl_read() can be used to
exchange data between GEM applications running concurrently. In
practice however, some problems need to be solved to make good use of
these two functions:
- There are no standard messages for exchanging data. Their
definition is the main goal of XAcc.
- appl_write() needs the receiver's application identifier (apid).
The only way to get this (before AES 4.0) is to call appl_find(),
which needs the receiver's name. Thus communication is only possible
if the sender knows the receiver's name. This problem is solved in AES
4.0 by the introduction of the function appl_search().
- The main application does not know when an accessory is activated
or deactivated. This would often be useful, for example if the main
application changes system variables that could affect the accessory's
behaviour. If the main application were informed before the accessory
gains control, it could reset those to their old values and change
them back after the accessory is finished. Another advantage would be
that after an accessory has been called, the main application could
check if something has been written to the clipboard (2) or if other
changes to the environment have been made.
With multitasking GEM, the situation has changed in several important
ways. The possibility of using several 'main' applications in parallel
makes it even more undesirable to let them directly manipulate system
variables and the like; nevertheless there will probably always remain
some purposes that require such methods. On the other hand, at least
for applications using windows (the preferred method to get the most
out of a multitasking system) it is now possible to detect changes of
the active application by interpreting the new AES messages WM_ONTOP
and WM_UNTOPPED. Therefore it is not considered necessary for XAcc to
provide additional means to achieve this.
The communications protocol described in this document solves all
these problems. It was designed for two distinct purposes:
- Exchanging data of standard types between programs that have no
information about each other.
- Exchanging data between specific applications known to each
other. The standard protocol ensures that program combinations from
different vendors do not interfere with each other.
A potential problem caused by this protocol should be mentioned at
this point: for single-tasking GEM versions, it relies on the
currently undocumented fact that the main application's apid is always
zero. Without this assumption there is no way to exchange data without
using appl_find(). Although this fact is not documented, it holds for
all single-tasking versions of GEM in existence until now, both for
MS-DOS and the Atari ST (this information was confirmed by Digital
Research Germany). Of course the main application's apid may be
different in future versions, although there is no reason to change
the current behaviour for single-tasking systems. For AES 4.0 (and
later) the above assumption is not needed anyway, so no compatibility
problems are to be expected in the future.
A further requirement is that all programs not using this protocol
must ignore its messages. This should not be a serious problem, as all
GEM applications should ignore messages they do not understand. At the
time of writing no programs are known to violate this rule.