Topic       : TOS - das Betriebssystem
Author      : 
Version     : tos.hyp (5. März 2013)
Subject     : Programmieren/Atari
Nodes       : 3001
Index Size  : 93602
HCP-Version : 5
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Titel
@help       : 
@options    : +g -i -s +x +zz -t4
@width      : 70
View Ref-File15.13.2.2.1  Multitasking GEM versions                             TOS

The initialization procedure is much simpler in this case. Any 
application, i.e. both 'standard' applications and accessories, uses 
appl_search to detect all currently running AES processes when it is 
started. To each application or accessory (i.e. everything but system 
processes) it sends an ACC_ID message:

  msg[0]:  ACC_ID (0x400)
  msg[1]:  sender's apid
  msg[2]:  length of the message - 16, giving 0
  msg[3]:  program version number and message groups
  msg[4] und msg[5]:   pointer to sender's name
  msg[6]:  menu number (menu_id) as returned by menu_register
  msg[7]:  reserved

The low byte of msg[3] contains a bitmap indicating which message 
groups are understood by the sender. Bit zero is set for message group 
1, bit one for message group 2, and so on. This is independent of the 
message types which the sender might itself send to others. The sender 
of message must ensure that it is understood by the receiver. The high 
byte is used to indicate a program version number using an arbitrary 
encoding scheme.

The pointer to the sender's name is stored in a processor-dependent 
format. The name itself is a string of characters terminated by two 
zero byte. To avoid name conflicts, long names are preferred to short 
abbreviations. The name must be available at the given address at any 
time, it may not be removed after initialization. It must also reside 
in globally accessible memory. As the version number is stored in 
msg[3], it should not occur again in the name. [Note: see the section 
"Extended names" for more details on names.]

Applications using more than one menu entry must issue one ACC_ID 
message for each entry used. Accessories without a menu entry must use 
a number of -1.

When receiving an ACC_ID message, an application replies by sending a 
message of the same format to the original sender, the only difference 
being that ACC_ACC is used instead of ACC_ID. Applications with 
several menu entries must again send one message for each entry.

The messages ACC_OPEN and ACC_CLOSE are not used in multitasking 
systems.

Note: The only difference between ACC_ID and ACC_ACC for multitasking 
systems is that an application receiving ACC_ID sends ACC_ACC as a 
reply, whereas no reply is sent on receiving ACC_ACC. This prevents 
applications from sending ACC_ID to each other indefinitely. Obviously 
the name ACC_ACC has lost its original meaning and probably should be 
changed. But since the symbolic names do not influence the actual 
behaviour of any program, this is not really important at all.

Since in a multitasking environment every participating application 
can terminate, some means must be provided to tell other applications 
about this. Therefore the message ACC_EXIT has been added to the list 
of level 0 messages. Before terminating, any application sends

  msg[0]:  ACC_EXIT (0x404)
  msg[1]:  sender's apid
  msg[2]:  length of the message - 16, giving 0

to all applications that have ever registered themselves by sending 
ACC_ID or ACC_ACC.