Topic       : TOS - The Operating System
Author      : 
Version     : tos.hyp (December 19, 2008)
Subject     : Programmieren/Atari
Nodes       : 3010
Index Size  : 93790
HCP-Version : 5
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Title
@help       : 
@options    : +g -i -s +x +zz -t4
@width      : 70
View Ref-File13.13.1  Purpose of XAcc                                           TOS

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 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.