•  Back 
  •  System Services Protocol (SSP) 
  •  Index 
  •  Tree View 
  •  Cross references 
  •  Help page 
  •  Show info about hypertext 
  •  View a new file 
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.10.5  SSP Server registration                                   TOS

Messagesare currently undefined. Free AES message numbers have to be 
found and the SSP messages defined.

All SPAs have to register with the Server at installation and at every 
startup of the application. Here's how it works:

  1. Service Providing Application Server registration

     #define SSP_SPASREG

     First initial message from the SPA to the Server.

     AESmessage-buffer:

       [0] = SSP_SPASREG
       [1] = appl_id           - Application ID of SPA
       [2][3] = (long)services - Long bit vector for supported services
                                 (see below)

     Put your application ID into messagebuf[1]. messagebuf[2]/[3] is 
     a 32bit LONG value that describes the services provided by the 
     application, composed as follows:

     #define SSP_PSENDFILE        0x01
     #define SSP_PSTATUSDISPLAY   0x02
     #define SSP_PDISPLAYMESSAGE  0x04
     #define SSP_PSENDMESSAGE     0x08
     #define SSP_PUPLOADFILE      0x10
     #define SSP_PCOMPRESSFILE    0x20
     #define SSP_PCONTEXTPOPUP    0x40
     #define SSP_PDISPLAYINFO     0x80

     Bringing the values together composes a bit-vector that tells the 
     Server which services are provided. Response to this message is 
     SSP_SREG.

  2. SSP Server Registration

     #define SSP_SREG

     AESmessage-buffer:

          [0] = SSP_SREG [1] = shmID - ID of shared memory block

     shmID is identification for a shared memory block provided by the 
     Server with this message.

     For example, if Smurf has appl_id 25, the registration shared 
     memory block is: u:/shm/25_reg.ssp

     This shm-block provides 4096 bytes of space and is read/write. 
     Copy the full path and name of your application into this memory 
     block, terminate with CRLF and append the long application name 
     of your app (like used in menu_register) and terminate with NULL 
     again. Example: d:\apps\misc\my_application.app[CRLF]My 
     Application[NULL]

     For the special case that your application has changed the long 
     app name in a new version, terminate the application name with 
     CRLF instead of NULL and append other possible old application 
     names, then terminate with NULL:

     d:\apps\misc\my_application.app[CRLF]My old application[CRLF]My 
     newer Application [CRLF]My current Application[NULL]

     Respond to the Server with SSP_SPARF.

  3. SSP Service Providing Application Registration Finish

     #define SSP_SPARF

     AESmessage-buffer:

       [0] = SSP_SPARF
       [1] = appl_id           - Application ID of SPA
       [2] = version as BCD    - Version ID of SPA

     Upon sending this message, the shm-block provided with SSP_SREG 
     must contain the full path and name of your application.

     The version ID is a binary coded decimal. For example, for 
     Version 1.0 of your program pass 0x0100. Version 1.01 would be 
     0x0101, 12.10 would be 0x1210. The version number in combination 
     with the long application name will provide pretty safe 
     identifications of applications for the Server, which will make 
     automatic registration and configuration update possible.

     This message closes the registration session. The Server will 
     take the sent data into its configuration and update existing 
     configurations for this application with the new one.