<concept xml:lang="en" id="GUID-A4B391F0-058F-5B51-8D28-6A7B5C4A1BB9"><title>v5.1-v6.1 legacy Unicode resource format</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>This page describes the resource file format introduced with the first Unicode version of Symbian OS, v5.1. This was based on the resource-file format used from the initial version of Symbian platform. The format uses no compression at all. </p> <p>Resource files in this format are generated by the resource compiler from v5.1 up to, but not including, Symbian OS v7.0. </p> <table id="GUID-C389837C-9CFD-5197-9C47-1F8C679190DF"><tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/><tbody><row><entry><p> <b>Number of bytes</b> </p> </entry> <entry><p> <b>Description</b> </p> </entry> </row> <row><entry><p>2</p> </entry> <entry><p>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). </p> </entry> </row> <row><entry><p>2</p> </entry> <entry><p>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. </p> </entry> </row> <row><entry><p>[any] </p> </entry> <entry><p>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. </p> </entry> </row> <row><entry><p>(number_of_resources+1)*2 </p> </entry> <entry><p>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). </p> <p>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. </p> <p>This last entry in the resource index, which stores 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. </p> </entry> </row> </tbody> </tgroup> </table> </conbody></concept>