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.1  AV protocol                                                  TOS

The AV protocol (Accessory-Venus) was developed by Stefan Eissing and 
used for the first time in the alternative desktop Gemini. Since then 
however this protocol has been supported in many further shells (Ease, 
Jinnee, MagXDesk, Thing, ...).

This section describes the version of the protocol from the Gemini 
distribution of 29th January 1995 (Gemini 1.a). All references to 
'Venus' in the following can be substituted with 'Client' or 'Server' 
as appropriate when using other shells.

The communication between two processes takes place with AV protocol 
via the exchange of (extended) AES messages, which can be allocated to 
one of the following categories:

   . AV functions (Client -> Server)
   . VA functions (Server -> Client)

Warning: Here one must point out that with a view to future operating 
system versions, memory blocks used for communication between various 
programs, or allocated via pointers, have to be global (Mxalloc 
function with Global flag set). Otherwise memory protection violations 
would arise on computers with PMMU (e.g. Atari TT030 or Falcon030).

If paths or filenames are to be included in messages, then one must 
always quote the absolute path (i.e. including the drive) and the 
drive letters must be in upper case. Paths should always end with a 
backslash!

With an AV_PROTOKOLL call, each application can inquire which messages 
are unnderstood (not all shells support the complete protocol). It 
would be nice if other programs too would react to this protocol. At 
least AV_SENDKEY is certainly easy to implement and is the only method 
by which keypresses can be simulated via messages.

Under normal TOS, a desk accessory that has received an AC_CLOSE 
message from the AES inquires of the application (with ID) 0 via 
AV_PROTOKOLL whether it has understood this. In a multitasking 
environment (MultiTOS, MiNT/N.AES or MagiC) the program need no longer 
have the ID 0; besides, there will be (hardly) any AC_CLOSE messages 
any more. In addition, not just desk accessories but also normal 
programs will want to communicate with the AV-Server. So what do we 
do?

If more than one main application can exist, then the program or the 
desk accessory should try to extablish contact with GEMINI. After all, 
the ID can be obtained with appl_find. If this fails, then one can 
still search for AVSERVER or the contents of the (AES) nnvironmental 
variable AVSERVER. The latter possibility in particular permits easy 
configuration from the outside. The new versions of the library VAFUNC 
by Stephan Gerle (available in well-sorted mailboxes) proceed in 
almost the same way.

See Also: Messages   Drag&Drop protocol   OLGA protocol