Namespaces

Variants
Actions

Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.

Symbian OS Internals/Appendix 2: The E32ImageHeader

From Wiki
Jump to: navigation, search
Article Metadata
Compatibility
Platform(s):
Symbian
Article
Created: hamishwillee (17 Jan 2011)
Last edited: hamishwillee (26 Jul 2012)

This section describes the image header for Symbian OS executable files, as defined in the file F32IMAGE.H. There are three formats for the E32ImageHeader:

  • Basic format - header contains no compression, security or version number information
  • J-format - header may contain compression information. In addition to the basic format fields, if the compression type (at offset 1C) is nonzero, the header includes an extra field holding the uncompressed size of the file
  • V-format - the executable contains versioning and security information. In addition to the basic and J-format fields, the header includes extra security and versioning related fields.

Basic format fields:

Offset
(hex)
Description of field
00 UID 1
04 UID 2
08 UID 3
0C Checksum of UIDs.
10 Signature (EPOC = 0x434F5045).
14 CRC-32 of entire header for V-format, CPU identifier for original and J-formats.
18 Version number of this executable - a 16-bit major and a 16-bit minor version number. This is used in link resolution (V-format only). In original format, this contained a checksum of the code, but this was never used.
1C Type of compression used (UID or 0 for none).
20 Version of PETRAN/ELFTRAN which generated this file.
24 Time at which file was generated, in standard EPOC encoding (microseconds since 00:00:00 01-01-00AD).
2C Flags field - see later in this appendix for more details.
30 Code size (includes constant data, IAT and export directory).
34 Initialized data size.
38 Heap minimum size (only used for EXEs).
3C Heap maximum size (only used for EXEs).
40 Stack size (only used for EXEs).
44 BSS (zero-filled data) size.
48 Offset in code of entry point.
4C Code base address (where code is linked for).
50 Data base address (where data is linked for).
54 Number of DLLs referenced.
58 Offset into the file of the export address table.
5C Number of entries in export address table.
60 Size of text section (offset of IAT within code section).
64 Offset in file to code section.
68 Offset in file to data section.
6C Offset in file to import section.
70 Offset in file to code relocations.
74 Offset in file to data relocations.
78 Priority of this process (only used for EXEs).
7A CPU (0x1000 = X86, 0x2000 = ARM).

For J-formatted headers, if the Type of compression field is nonzero, then the following field will be present. For V-formatted headers, it is always present:

7C Uncompressed size of the file.

For V-formatted headers, the following fields will be present:

80 Security information (capabilities, secure ID, vendor ID).
90 Offset from start of code section to exception descriptor (for C++ exception unwinding) + 1. Bit 0 is set if this is valid, bit 0 is clear if there is no exception descriptor.
94 Spare.
98 Size of bitmap description holes in the export table.
9A Format of bitmap describing holes in the export table (described later in this appendix).
9B Bitmap describing any holes in the export table. This is a variable length field.

The flags field at offset 2C in the header is a bitmapped field, defined as follows:

Bits Size in
bits
Description
0 1 Executable type:
0 - EXE
1 - DLL
1 1 Whether to call entry point (not used in EKA2):
0 - call entry point
1 - don't call entry point
2 1 Whether this is a fixed address EXE:
0 - not fixed address
1 - fixed address
4-3 2 ABI:
0 - GCC98r2
1 - EABI
7-5 3 Entry point type:
0 - EKA1
1 - EKA2
23-8 16 Reserved
27-24 4 Header format:
0 - Basic
1 - J-format
2 - V-format
31-28 4 Import format:
0 - Standard PE format
1 - ELF format
2 - PE format without redundant copy of import ordinals. Standard PE format is only used with original
and J-format headers. V-format headers are either ELF or PE without redundant import ordinals.

For V-formatted headers, the field describing the format of the export table bitmap may have one of the following values:

Value Description
00H No holes, all exports are present.
01H A full bitmap is present, that is, there is one bit for each export
directory slot - a 1 indicates export present, a 0 indicates export
absent.
02H A sparse bitmap is present (granularity 8). This consists of two sections. The first section contains one bit for each group of eight consecutive export directory slots. A 0 bit indicates that all these slots contain valid exports and no further description of them is necessary. A 1 bit indicates that at least one of the eight exports is absent, and there is a bit mask byte in the second section describing which of the eight is present. The bytes in the second section occur in the same
order as the bits in the first section.
FFH XIP file.


Licence icon cc-by-sa 3.0-88x31.png© 2010 Symbian Foundation Limited. This document is licensed under the Creative Commons Attribution-Share Alike 2.0 license. See http://creativecommons.org/licenses/by-sa/2.0/legalcode for the full terms of the license.
Note that this content was originally hosted on the Symbian Foundation developer wiki.

This page was last modified on 26 July 2012, at 05:39.
37 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×