Chunk type-specific data structures

Chunks with data of type 0xEE and sub-type 0x0011 contain data organized as a record.

Chunk type-specific data structures are used by the event audit system to store the event log, and by the ZIMT scripting language to store properties and parameters of variables. This record format appears to be indicated by one or more values in record data (one of them being the first byte of the record data). The record formats of the chunk types given here are guesses.

Data type Chunk data
Sub-type Byte length of and record data Record data
0 1 2 3 4 5 6 7 8 … n
0xEE 0x11 0x00 LSB     MSB        

ZIMT parameter and property chunks

The record data of the chunks with data type 0xEE and sub-type 0x0011 is described in the tables below. For the sake of brevity, the following definition of record elements will be used:

byte
1 byte
byte (boolean)
1 byte with values limited to 0x00 and 0x01
word
2-byte integer
long
4-byte integer
single
4-byte single-precision float
double
8-byte double-precision float
string
variable-length unicode string (see Unicode strings)
list
variable-length data list (see Lists of data)
tuple
ordered group of values

ZIMT property chunks

Chunk type name Record data
Count Type
QS_Par 1 byte 0x01
1 byte (boolean)
2 byte
1 byte (boolean)
Chunk type name Record data
Number Type
QS_ValPar 1 byte 0x01
1 double
1 string
1 word
1 list of doubles
1 list of bytes
1 byte 0x00
 
Record contains value, unit, and ID. Lists are often empty.
Chunk type name Record data
Number Type
QS_TextPar 1 byte 0x01
4 string
 
String 2 contains language information,
strings 3 and 4 are empty.
Chunk type name Record data
Number Type
QS_SelPar 1 byte 0x02
1 long
1 list of longs
4 string
 
The first long is 0xFFFFFFFF if the list is not empty.
String 2 contains language information,
strings 3 and 4 are empty.
Chunk type name Record data
Number Type
QS_ValArrPar 1 byte 0x02
1 string
1 word
1 byte, usually 0x00
1 list of longs
 
The word contains an ID value.
Chunk type name Record data
Number Type
QS_ValArrParElem 1 byte 0x02
1 list of tuples of type (long, double)
 
Tuples are pairs of index and value.
Chunk type name Record data
Number Type
QS_ArrPar 1 byte 0x02
1 list of longs
1 byte

ZIMT parameter chunks

Chunk type name Record data
Number Type
QS_ParProp 1 byte 0x07
9 byte (boolean)
1 word
9 string
3 word
5 string
1 long 0x00000000
2 word
1 byte
1 string
4 byte (boolean)
 
Bytes 6 and 9 seem to always be 0x00.
The 3 words are 0x0000, 0xFFFF, 0xFFFF.
The last 4 bytes are 0x00, 0x01, 0x00, 0x01.

or

Chunk type name Record data
Number Type
QS_ParProp 1 byte 0x07
9 byte (boolean)
1 word
9 string
3 word
5 string
1 long 0x00000002
2 word
1 byte
1 long
1 string
4 byte (boolean)
 
The last 4 bytes are 0x00, 0x01, 0x00, 0x01.
Chunk type name Record data
Number Type
QS_ValProp 1 byte 0x01
1 byte (boolean)
2 byte
1 byte (boolean)
Chunk type name Record data
Number Type
QS_TextProp 1 byte 0x01
4 byte
4 byte (boolean)
 
The last byte is 0x01
Chunk type name Record data
Number Type
QS_SelProp 1 byte 0x04
3 byte (values)
1 list of 4 strings
1 list of 4 strings
1 list of strings
1 list of strings
1 list of words
1 list of longs
1 list of strings
 
Record data may end after the first three bytes.
If present, all lists are of the same length.
Chunk type name Record data
Number Type
QS_ValArrParProp 1 byte 0x02
4 byte
1 word
4 byte
Chunk type name Record data
Number Type
QS_SkalProp 1 byte 0x02
2 string
2 byte (boolean)
 
First string may contain a ZIMT script.
The booleans seem to indicate validity of the respective strings.
Chunk type name Record data
Number Type
QS_ValSetting 1 byte 0x02
2 string
1 long
1 string
3 byte
1 word
2 byte
1 list of words
1 list of strings
1 byte
10 byte
 
The leading strings are usually empty.
The long is small-valued.
The word is either 0x0000 or 0xFFFF.
If not empty, the list of words contains ID values.
If not empty, the last string contains a variable name.
Chunk type name Record data
Number Type
QS_NumFmt 1 byte 0x02
4 byte
1 double
 
The value of the double float is usually 0.1.
Chunk type name Record data
Number Type
QS_Plaus 1 byte 0x01
9 byte, usually 0x00
6 byte, usually 0xFF or 0x00
1 word, usually 0xFFFE or 0x0000
6 byte, usually 0xFF or 0x00
1 word, usually 0x7FFE or 0x00
6 byte, usually 0x00
 
Note that data in this chunk differ from QS_Tol
only in length.
Chunk type name Record data
Number Type
QS_Tol 1 byte 0x01
9 byte, usually 0x00
6 byte, usually 0xFF or 0x00
1 word, usually 0xFFFE or 0x0000
6 byte, usually 0xFF or 0x00
1 word, usually 0x7FFE or 0x00
3 byte, usually 0x00
 
Note that data in this chunk differ from QS_Plaus
only in length.

Event audit chunk

The event audit log is stored in a chunk type with name Entry. The description below represents the parsing algorithm used before version 0.3.0. In the current implementation, the chunk is parsed heuristically as bytes and strings.

[START OBSOLETE DESCRIPTION]

The first byte of the record (i.e., format code) corresponding to the description here is 0x02. A large number of Entry–Record-Format-Codes (ERFC) and associated records are defined. However, it appears to be possible to split the record data into its constituents without interpreting the format code explicitly. The procedure is described in the Section Parsing algorithm.

In addition to strings, the following prefixed data types are defined that are specific to Entry chunks:

Prefix Data block Total length of data type (bytes)
Length (bytes) Interpretation
0x07 8 1 double 9
0x64 4 1 long 5
0x01 4 4 bytes 5
0x04 1 1 byte 2

Data type and chunk data of an Entry chunk start as follows:

Data type Chunk data
Sub-type Byte length of format code and record data Record data
Format ERFC 3-tuple String
0 1 2 3 4 5 6 7 8 9 10 11 …
0xEE 0x11 0x00 LSB     MSB 0x02          

Parsing algorithm

The following algorithm appears to be able to parse record data data into a list, regardless of record format code. The algorithm is completely heuristic and is able to extract a lot of meaningful information. However, it should be replaced with an algorithm evaluating the ERFC code.

  1. Go to start of record.
  2. Read and output ERFC byte.
  3. Interpret next 3 bytes as 3-tuple and output.
  4. While there are bytes left to parse:
  1. If string follows: interpret and output string, continue at 3.
  2. If the next byte belongs to a prefixed data type and another prefixed data type or string follows the current data block: interpret prefixed data type and output, continue at 3.
  3. If another prefixed data type or string follows 4 bytes later: interpret 4 bytes as 2 words and output, continue at 3.
  4. If another prefixed data type or string follows 2 bytes later: output 2 bytes, continue at 3.
  5. Output next byte, continue at 3.

The test for follow-up prefixed data type or string needs to verify that either the end of the string is reached or

  1. that the following data starts with a prefix defined for prefixed data types or with a string length followed by 0x00 0x80, indicating strings, and
  2. that the following number of bytes is sufficient to hold the entire prefixed data type or string.

The purpose of the follow-up test is to prevent the detection of spurious unicode string markers LSB MSB 0x00 0x80 in the binary prepresentation of double-precision floating point numbers.

Interpretation

Each Entry record begins with a common header, followed by a detailed, entry-specific record. The common header contains the following entries:

  1. Entry-record-format-code
  2. 3-tuple
  3. User name currently logged into the system
  4. Time in seconds, possibly since loading/saving a file.
  5. An ID (always the same)
  6. Empty string
  7. Another ID (always the same)
  8. The value 0
  9. A string giving a human-readable, brief description of the event
  10. Internal string describing the originator of the event

[END OBSOLETE DESCRIPTION]