storage/resources/ResourcesFormat.tex

41 attributes resources are part of the file contents and thus do not require a
45 additionally contain resources -- namely the ELF and PEF object formats.
131 alignment padding and, of course, the resources themselves.
133 Therefore two values have to be known: The size of the actual ELF file and the
137 table (if any), section header table (if any), sections and segments.
140 \code{kELFMinResourceAlignment} and the alignments of the segments in the file.
146 The data used for the padding between the end of the actual ELF data and the
168 endianess, that is the resources created by little endian and big endian
216 \item{An administrative section which comprises the resources header and the
225   such as type, id and name.
284 resource, and the section ends with a special padding.
354 the size of \code{resource\_index\_entry} and the number of resources.
404 pattern specified by \code{kUnusedResourceDataPattern}, and that only those
408 To be precise: Let \verb|uint32 resources[]| be the resources and
421 Such an entry (resource info) specifies the ID and name of a
492   not have a name and \code{ri\_name} has a size of 0.
497   terminating null). If it is 0, the resource does not have a name and
539   \code{rite\_check\_sum} and \code{rite\_terminator}. The data are grouped
541   and summed up, ignoring carry. If the number of bytes to be considered is
561 and that are handled gracefully by xres and QuickRes. It follows a, possibly
565 \item{The third and fourth byte of the x86 resource file magic (the 0 bytes)
579   (see section \ref{resources-infotable}) and thus no check sum. The table
591 namely QuickRes and xres. They are incomplete and may even be partially wrong,
600   the usual memory page size of current x86 architectures and therefore the
608   in fact not even the exact length and meaning of the fields of the resources
610 \item{The unknown section: The contents of the unknown section and of unknown