Resource file formats supported in Symbian OS 7.0
Introduction
This document describes the three resource-file formats supported by Bafl’s RResourceFile class in Symbian OS version 7.0.
The legacy format introduced with the first Unicode release (ER5u)
This resource-file format has uses no compression at all. It was introduced with the first Unicode version of Symbian OS (ER5u) and is based on the resource-file format used in the very first version of the 32-bit Symbian OS. Resource files in this format are generated by Rcomp.exe from version ER5u up to, but not including, version 7.0 of Symbian OS.

Number of bytes	Description	
2	This two-byte integer (in “little-endian” byte order) stores the file-position of the start of the resource index (see the last row of this table for a description of the resource index).	
2	This two-byte integer (in “little-endian” byte order) stores 1 + the size of the resource index in bytes. (The addition of 1 was to distinguish this resource file format from an older, now obsolete, resource-file format)	
[any]	This contains the data for all the resources stored in order, one after another with no byte-padding between them. The binary data of each resource is laid out exactly as specified in the resource definition, with the exception that extra padding bytes (arbitrarily 0xab) are inserted in front of any Unicode text-string that would otherwise not be aligned on a two-byte boundary relative to the start of that resource’s data.	
(number_of_resources+1)*2	This is the resource index which is a series of two-byte integers (in “little-endian” byte order), one for each resource in the resource file, each storing the file-position of that resource’s data (see row immediately above). This is followed by a two-byte integer (in “little-endian” byte order) which is the file-position one byte past the end of the last resource’s data. (This is so that working out the length of a resource’s data is trivially done by subtracting the file-position stored in that resource’s index-entry from the file-position in the next index-entry.) This last entry in the resource index (storing the file-position one byte past the end of the last resource’s data) can also be thought of as storing the file-position of the start of the resource index. (This means that resource files in this format have the same two-byte integer at the very start and at the very end of the file.)	

The format containing compressed Unicode
This resource-file format compresses (for those cases where actual benefit is yielded by compressing) Unicode text-strings in the resource data by using the Standard Compression Scheme for Unicode described in http://www.unicode.org/unicode/reports/tr6/tr6-3.2.html. Resource files in this format are generated by Rcomp.exe in version 7.0 of Symbian OS.

Number of bytes	Description	
16	These bytes store the resource file’s UIDs. The first twelve bytes consist of three four-byte integers (in “little-endian” byte order) followed by a four-byte CRC checksum generated from those three integers. The first UID is always 0x101f4a6b. The second and third UIDs can be specified on Rcomp.exe’s command-line. By default the second UID is zero and the third UID is the resource file’s “offset”, i.e. the twenty-bit integer generated from the resource file’s name (these twenty bits are stored in the least significant twenty bits of the third UID – the most significant twelve bits are all zero).	
1	This byte stores flags. Currently there is only one flag defined which is the lowest bit of the byte (0x01). This flag indicates whether the third UID is actually the resource file’s “offset” (see the row above). The bit is set to non-zero if it is, and zero if it is not.	
2	This two-byte integer (in “little-endian” byte order) stores the size in bytes of the largest resource in the file (that is, the size when uncompressed).	
Number_of_resources/8 (rounded up to the nearest whole number)	This is a bit-array (one bit for each resource) storing which resources contain compressed Unicode. The least significant bit of the first byte corresponds to the first resource, the next-to-least significant bit of the first byte corresponds to the second resource, etc. A bit being set to non-zero indicates that the corresponding resource contains compressed Unicode, a zero bit indicates that it does not contain compressed Unicode.	
[any]	This contains the data for all the resources stored in order, one after another with no byte-padding between them. The format of the data for each resource is in one of two possible formats depending on whether the resource contains compressed Unicode. The bit-array described in the row above indicates which resources contain compressed Unicode. Note that resources in either of these two formats may contain uncompressed Unicode (this is because compressing Unicode using the Standard Compression Scheme for Unicode can, in certain conditions, yield larger output than input, hence such Unicode text-strings will not be “compressed” as it would not be beneficial). Extra padding bytes (arbitrarily 0xab) are inserted in front of any uncompressed Unicode text-string that would otherwise not be aligned on a two-byte boundary relative to the start of that resource’s data, once the resource has been uncompressed.
Resources not containing compressed Unicode:
The binary data of these resources is laid out exactly as specified in the resource definition (although note the comment about padding bytes above).
Resources containing compressed Unicode:
The binary data of these resources is split up into one or more “runs” alternating between compressed Unicode and “other stuff”. Each run is preceded by an integer containing the length in bytes of the run (not including the byte(s) it occupies itself). The run-length occupies a single byte if it is less than 128, otherwise it occupies two bytes (in “big-endian” byte order) with the most significant bit of the first byte set to non-zero to indicate that the run-length occupies two bytes. Only the length of the first run may be zero (which would be the case if the resource does not start with compressed Unicode).	
(number_of_resources+1)*2	This is the resource index which is a series of two-byte integers (in “little-endian” byte order), one for each resource in the resource file, each storing the file-position of that resource’s data (see row immediately above). This is followed by a two-byte integer (in “little-endian” byte order) which is the file-position one byte past the end of the last resource’s data. (This is so that working out the length of a resource’s data is trivially done by subtracting the file-position stored in that resource’s index-entry from the file-position in the next index-entry.) This last entry in the resource index (storing the file-position one byte past the end of the last resource’s data) can also be thought of as storing the file-position of the start of the resource index.	

Dictionary-compressed resource files
Resource files of this format are generated from files in the format containing compressed Unicode (described immediately above).

Number of bytes	Description	
16	These bytes store the resource file’s UIDs. The first twelve bytes consist of three four-byte integers (in “little-endian” byte order) followed by a four-byte CRC checksum generated from those three integers. The first UID is always 0x101f5010. The second and third UIDs are the same as the second and third UIDs of the file from which the dictionary-compressed resource-file is generated.	
1	The least significant three bits:
This stores the number of bits used for dictionary references, storing this value as an offset from 3, i.e. if 2 is stored in these three bits then the number of bits per dictionary reference would be 3+2=5. Thus the number of bits per dictionary reference may range inclusively from 3 (=3+0) to 10 (=3+7). The maximum number of dictionary entries for each number of bits per dictionary reference is therefore 8 (=23), 16 (=24), 32 (=25), 64 (=26), 128 (=27), 256 (=28), 512 (=29), 1024 (=210).
The most significant five bits:
This stores flags. Currently there are three flags defined.
•	The most significant bit (0x80) indicates whether the third UID is actually the resource file’s “offset” (see the first row of the preceding table for a description of what the “offset” is). The bit is set to non-zero if it is, and zero if it is not.
•	The second-most significant bit (0x40) indicates whether the first resource in the resource file (from the client’s point of view) is an RSS_SIGNATURE with default values for which no data is actually stored later in the resource file. The bit is set to non-zero if it is, and zero if it is not. This flag must only be on if the third UID of the resource file is the resource file’s “offset” (see the 0x80 flag described immediately above).
•	The third-most significant bit (0x20) indicates whether the bit-array storing which resources contain compressed Unicode has been stored as a resource before the client’s actual resources. (If it is stored as a resource, it benefits by being dictionary-compressed.) The bit is set to non-zero if the bit-array is stored as a resource, and zero if it is simply stored as a field on its own (see the fifth row of this table).
Note that the bit-array will not contain a bit that refers to the “non-stored” (if the 0x40 flag is on) initial RSS_SIGNATURE resource. It will also not contain a bit that refers to itself if it is stored as a resource (i.e. if the 0x20 flag is on).	
2	This two-byte integer (in “little-endian” byte order) stores the size in bytes of the largest resource in the file (that is, the size when uncompressed with regard to both dictionary-compression and compressed Unicode).	
2	This two-byte integer (in “little-endian” byte order) stores the file-position of the start of the resource data (see the penultimate row of this table for a description of the resource data).	
Number_of_resources/8 (rounded up to the nearest whole number), or zero if the 0x20 flag (described in the second row of this table) is on	This is a bit-array (one bit for each resource) storing which resources contain compressed Unicode. This field is not always present (see the left-hand column).	
[any]	This contains the data for all the dictionary entries stored one after another with no bit-padding between them, encoded according to the scheme described in the next table. The last dictionary entry, if not finishing on a byte-boundary, is followed by zero pad-bits up to the next byte-boundary.	
Number_of_dictionary_entries*2	This is the dictionary index which is a series of two-byte integers (in “little-endian” byte order), one for each dictionary entry, each storing the offset in bits from the start of the entire dictionary data to one-bit past the end of that dictionary entry’s data (see row immediately above).	
[any]	This contains the data for all the resources stored in order, one after another with no bit-padding between them, encoded according to the scheme described in the next table. The data for the last resource, if not finishing on a byte-boundary, is followed by zero pad-bits up to the next byte-boundary.	
Number_of_resources*2, or (number_of_resources-1)*2 if the 0x40 flag (described in the second row of this table) is on	This is the resource index which is a series of two-byte integers (in “little-endian” byte order), one for each stored resource, each storing the offset in bits from the start of the entire resource data to one-bit past the end of that resource’s data (see row immediately above).	

The data for each dictionary entry and the data for each resource consist of zero, one or more of the following bit-sequences shown in the table below. Note that the order of bits is taken as going from least-significant to most-significant. Thus, for example, the binary prefix 10 (assuming that these bits were not split across a byte-boundary) would actually be stored with the 1 in the less significant bit of the bit-pair and the 0 in the more significant bit.

Prefix bits	Description of what follows	
0	This is followed by a dictionary reference (the second row of the previous table describes the field indicating how many bits a dictionary reference occupies). A dictionary reference is a zero-based index* into the dictionary entries, i.e. a dictionary reference of 0 indicates the first dictionary entry, and dictionary reference of 1 indicates the second dictionary entry, etc.	
10	This is followed by one octet of data, the least significant bit of the octet being stored first.	
110	This is followed by two octets of data, the least significant bit of the first octet being stored first.	
1110	This is followed by a three-bit integer* storing the number of subsequent octets minus 3, followed by those octets themselves (the least significant bit of the first octet being stored first). Use this to store a run of between 3 and 10 octets (inclusive).	
1111	This is followed by an eight-bit integer* storing the number of subsequent octets minus 11, followed by those octets themselves (the least significant bit of the first octet being stored first). Use this to store a run of between 11 and 266 octets (inclusive).	

* These integers, if split across one or more byte-boundaries are stored in little-endian “byte-order”, i.e. the segment of the integer stored in the “next” byte store more significant bits than the segment of the integer stored in the “current” byte.