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.

0. Go to start of record.

1. Read and output ERFC byte.

2. Interpret next 3 bytes as 3-tuple and output.

3. While there are bytes left to parse:

4. If string follows: interpret and output string, continue at 3.

5. 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.

6. If another prefixed data type or string follows 4 bytes later: interpret 4 bytes as 2 words and output, continue at 3.

7. If another prefixed data type or string follows 2 bytes later: output 2 bytes, continue at 3.

8. 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]