home *** CD-ROM | disk | FTP | other *** search
/ Amiga Times / AmigaTimes.iso / programme / GoldED / developer / registry / README
Encoding:
Text File  |  1998-10-06  |  5.3 KB  |  142 lines
  1. COPYIGHT
  2.  
  3.   ©1996 Dietmar Eilert, All Rights Reserved.
  4.  
  5.   Dietmar Eilert
  6.   Mies-v-d-Rohe-Str.31, 52074 Aachen, Germany
  7.   E-Mail: DIETMAR@TOMATE.TNG.OCHE.DE
  8.   Tel: +49-(0)241-81665
  9.        +49-(0)2525-7776
  10.   Fax: +49-(0)241-81665
  11.  
  12.  
  13. REGISTRY
  14.  
  15.   GoldED  4  stores  global   configuration   data   in   the   registry   file
  16.   "golded:registry/registry".   The  registry  is  loaded  during  startup.  It
  17.   includes definitions of all filetypes. Local configurations are stored in the
  18.   directory "golded:registry/presets". These files are listed as preset pool in
  19.   GoldED's filetype configuration requester. Pointers to  these  files  can  be
  20.   found  in  the registry, ie. the registry defines if and when those files are
  21.   used.
  22.  
  23.  
  24. CONFIGURATION FORMAT
  25.  
  26.   GoldED uses an object-oriented format for configuration data (on disk and  at
  27.   run  time): Every configurable option is described by an object. The run time
  28.   object format is descibed below:
  29.  
  30.   struct Object {
  31.  
  32.       struct Node Node;
  33.  
  34.       UWORD                 ID;
  35.       UWORD                 Type;
  36.       struct Class         *Class;
  37.  
  38.       union {
  39.  
  40.           ULONG             Number;
  41.           UBYTE            *String;
  42.           struct List      *List;
  43.           APTR              Data;
  44.  
  45.       } Value;
  46.   };
  47.  
  48.   /* object types (bit 0-2) */
  49.  
  50.   #define OBJECT_TYPE_NUMBER     1
  51.   #define OBJECT_TYPE_STRING     2
  52.   #define OBJECT_TYPE_LIST       3
  53.   #define OBJECT_TYPE_DATA       4
  54.   #define OBJECT_TYPE_NAMED      8
  55.  
  56.   /* special object ID
  57.  
  58.   #define OBJECT_LOCKED ((UWORD)~0)
  59.  
  60.   NODE:
  61.  
  62.   Objects are linked together (except a few root  objects).  Some  objects  are
  63.   named  (see  below):  a  pointer  to  the  object's  name  is  then stored in
  64.   object->Node.ln_Name. The node's ln_Pri is used to coordinate access:  it  is
  65.   set  to OBJECT_LOCKED if an object is currently in use and may not be deleted
  66.   or modified (except by the owner of the object).
  67.  
  68.   ID:
  69.  
  70.   ID is the object ID. Most objects in GoldED have a unique  ID.  For  example,
  71.   OBJECT_GLOBAL_FINDTEXT  refers  to  the object that is used to store the last
  72.   find  string.  Current  ID   definitions   can   be   found   in   the   file
  73.   "include/registry.h".
  74.  
  75.   TYPE:
  76.  
  77.   The object type. Four basic types are understood by  GoldED:  Number  objects
  78.   (OBJECT_TYPE_NUMBER)  can  store  a  single  number.  The number is stored in
  79.   <object->Value.Number>. They are used to store boolean  values,  too.  String
  80.   objects  (OBJECT_TYPE_STRING)  can store strings. A pointer to a 0-terminated
  81.   string is stored in <object->Value.String>. The string pointer may be NULL to
  82.   indicate  that the string is empty. Data objects (OBJECT_TYPE_DATA) can store
  83.   arbitrary memory  blocks.  A  pointer  to  the  memory  block  is  stored  in
  84.   <object->Value.Data>.  The  block  size  is  stored  in four bytes before the
  85.   memory block similar to how AllocVec() stores size information. List  objects
  86.   (OBJECT_TYPE_LIST)  can store lists of further objects. A non-NULL pointer to
  87.   the list structure is stored  in  <object->Value.List>.  The  list's  lh_Head
  88.   field  points  to  the  first  child object. The list of children may contain
  89.   further OBJECT_TYPE_LIST objects  with  their  own  sublists.  There  are  no
  90.   nesting limits (recursive programming required).
  91.  
  92.   Some objects are named. Named objects have the OBJECT_TYPE_NAMED bit  set  (a
  93.   pointer  to  the  name is stored in object->Node.ln_Name as mentioned above).
  94.   You have to mask the object type  with  0x7  to  filter  this  flag:  type  =
  95.   object->Type & 0x7
  96.  
  97.   CLASS:
  98.  
  99.   A pointer to the class that is  reponsible  for  object  handling  (creation,
  100.   disposal, etc.).
  101.  
  102.  
  103. FILE FORMAT
  104.  
  105.   The following paragraphe describes how the run-time format (linked  lists  of
  106.   objects) is saved to disk: this is a description of the format used by GoldED
  107.   to save the registry, configuration presets or recorded sequences.
  108.  
  109.   The first four bytes of every data file are "OOP" (0-terminated). Data  of  a
  110.   single  object  - the "root" object - follows: every GoldED OOP file consists
  111.   of a single root object without successor (however, the root  object  usually
  112.   is  a list object: It has no successor but it may have an unlimited number of
  113.   children).
  114.  
  115.   The physical format of how the object is stored in the file  depends  on  the
  116.   object  type  but  the basic structure is independend of the object type: The
  117.   first two bytes (UWORD) contain the object type  and  the  object  ID.  These
  118.   values  are  combined  to a "fat ID" to save disk space. The object ID can be
  119.   found in bit 0-10, the type can be found in bit 11-15 (ID  =  fatID  &  2047,
  120.   Type  =  fatID / 2048). Some objects are named and have the OBJECT_TYPE_NAMED
  121.   bit set (in <type>). The name - if available - is  stored  immediately  after
  122.   the fat ID as a 0-terminated string. The object's data follows:
  123.  
  124.   OBJECT_TYPE_NUMBER
  125.  
  126.      The object's numerical value is stored in the next four bytes (LONG).
  127.  
  128.   OBJECT_TYPE_STRING
  129.  
  130.      A 0-terminated byte sequence
  131.  
  132.   OBJECT_TYPE_DATA
  133.  
  134.      The block size stored in the next four bytes (ULONG) followed by the
  135.      specified number of raw bytes.
  136.  
  137.   OBJECT_TYPE_LIST
  138.  
  139.      The number of children stored in the next four bytes (ULONG)  followed  by
  140.      the specified number of child objects. Child objects are saved in the same
  141.      format as all other objects: fat ID (type/ID), name (if available), value.
  142.