Copy Link
Add to Bookmark
Report
Xine - issue #5 - Phile 117
Ú-----------------------------¿
| Xine - issue #5 - Phile 117 |
À-----------------------------Ù
Ú--ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ--¿
: The PRC Format by ULTRAS [MATRiX] :
À--ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ--Ù
------´ Introduction Ã------------------------------------------------------
I very long searched for the description PRC of files of their structure and
long could not find. Then I had some descriptions it (prc) of a format in
which the format of these files was on any other business is written and I
have decided to describe till this format. It is articles my attempt to
describe the given format of files.
As in this articles not mine will be described reflection on a theme of the
different phenomena in PRC header.
------´ Format PRC of a file Ã----------------------------------------------
So he is necessary for a beginning that such PRC a file and for what and
where is used as this file works how to load in a platform etc...
þ PRC files are basic executable files for Palm Pilot OS.
An application for the pilot is simply a Pilot resource database with a
number of mandatory resources (CODE 0, CODE 1, DATA 0, PREF 0, etc.) The PRC
file, then, is simply the flat file representation of a Pilot resource
database. When the PRC file is loaded into the Pilot, it is converted into a
resource database using the PalmOS routine dmCreateDatabaseFromImage().
The PRC format consists of the following major pieces:
þ PRC Header
þ PRC Resource Headers
þ PRC Resources
Ú--------------¿
| PRC Header |
À--------------Ù
The PRC Header is located at the very beginning of the file, and contains
the following information:
ÉÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍ»
º offset | Name | Type | Size º
ÈÑÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍѼ
| 0X00 | name | char | 32 |
Ã-------Å------------------Å--------------Å-----´
| 0x20 | flags | int | 2 |
Ã-------Å------------------Å--------------Å-----´
| 0x22 | version | int | 2 |
Ã-------Å------------------Å--------------Å-----´
| 0x24 | create_time | pilot_time_t | 4 |
Ã-------Å------------------Å--------------Å-----´
| 0x28 | mod_time | pilot_time_t | 4 |
Ã-------Å------------------Å--------------Å-----´
| 0x2c | backup_time | pilot_time_t | 4 |
Ã-------Å------------------Å--------------Å-----´
| 0x30 | mod_num | pilot_time_t | 4 |
Ã-------Å------------------Å--------------Å-----´
| 0x34 | app_info | int | 4 |
Ã-------Å------------------Å--------------Å-----´
| 0x38 | sort_info | int | 4 |
Ã-------Å------------------Å--------------Å-----´
| 0x3c | type | int | 4 |
Ã-------Å------------------Å--------------Å-----´
| 0x40 | id | int | 4 |
Ã-------Å------------------Å--------------Å-----´
| 0x44 | unique_id_seed | int | 4 |
Ã-------Å------------------Å--------------Å-----´
| 0x48 | next_record_list | int | 4 |
Ã-------Å------------------Å--------------Å-----´
| 0x4c | num_records | int | 2 |
À-------Á------------------Á--------------Á-----Ù
ù The name field is zero terminated and is usually zero padded. The pila
assembler sneaks 'Pila' into the last 4 bytes of this field
ù The 'flags' field is 0x01 for PRC executables. The 0x40 bit is set if
the executable is considered non-beamble. (Note that this means it's
probably fairly easy to make a non-beamble application to be beamable...)
ù The 'version' field is 0x01 for PRC executables
ù Pilot time is defined to be the number of seconds since January 1 1904
(as well as in Macintosh time).
ù (mod_num, app_info, sort_info) - This field must be zero for PRC
executables.
ù The 'type' field must be 'appl' for PRC executables
ù The 'id' field is a four character "creator code", ala the Macintosh
ù The 'num_records' field contains the number of resources in the PRC file.
Ú------------------------¿
| PRC Resource Headers |
À------------------------Ù
The Resource headers follow immediately after the PRC Header field. The
num_records field in the PRC Header indicates the number of resources
contained in the PRC file, and there is a 10 byte resource header for each
resource.
Ö--------Â------Â------·
º name | type | size º þ Resource Headers
Ç--------Å------Å------¶
º name | char | 4 º ù Name of the resource
º id | int | 2 º ù ID number of the resource
º offset | int | 4 º ù Pointer to the resource data
Ó--------Á------Á------½
You can be convinced that at PRC of files this header is very small...
Ú----------------¿
| PRC Resource |
À----------------Ù
The actual data for the resources follow after the resource headers. The
resource data records are stored in order as they appeared in the resource
headers. (Since the resource header does not have a size field, the size is
determined by examining the where the offset pointer for the next resource.)
The Mysterious Code #0 Resource
The contents of this resource have been (up until now) somewhat mysterious,
with different packages - Metroworks, Pila, and the obj-res program from the
prc-tools package - generating in some cases very different values.
Pila creates an 8 byte resource, with the first four bytes described as the
initialized data size and the next four bytes described as the unitialized
data size. Pila stores the size of the data segment in the first field, and
the second field is always filled with zeros.
The obj-res program from the prc-tools package does something quite different.
It creates a 24 byte resource, which is filled in as follows:
Ö--------Â-------------------------------------------·
º offset | value º
Ç--------Å-------------------------------------------¶
º 0 | 0x00000028 º
Ç--------Å-------------------------------------------¶
º 4 | [bss+data segments rounded up to 4 bytes] º
Ç--------Å-------------------------------------------¶
º 8 | 0x00000008 º
Ç--------Å-------------------------------------------¶
º 12 | 0x00000020 º
Ç--------Å-------------------------------------------¶
º 16 | 0x0000 º
Ç--------Å-------------------------------------------¶
º 18 | 0x3F3C º
Ç--------Å-------------------------------------------¶
º 20 | 0x0001 º
Ç--------Å-------------------------------------------¶
º 22 | 0xA9F0 º
Ó--------Á-------------------------------------------½
The obj-res program treated most of the fields in the 24 byte resource as
magic values,apparently o btained from looking at the contents of the code 0
resource from PRC files generated by the Metroworks compiler, since
applications generated by the Metrowerks compiler have similar code 0
resources.
But Metroworks it is the compiler for palm but the compiler works only in
MacOS, so we shall not consider it. Though some people have told that such
compiler is and for PC. Whether but I do not know so it because I it not
where did not meet.
This what for is necessary 0 in resources?
However, apparently not all of the code 0 resource is used by the Pilot, at
least not in PalmOS 1.0 or 2.0. For example, the Pila assembler only creates
a code 0 resource which is 8 bytes long, and PalmOS 1.0 and 2.0 don't seem
to mind that the rest of the code 0 resource isn't present.
I also tried selectively corrupting the jump table of an application
generated by the Metrowerks compiler, and this did not affect the behavior
of the application. Hence, it appears that the Pilot does not use the jump
table to determine the application start address.
A much more interesting way of confirming our observations thus far is to
consider the Pila's compilr alternative memory model. In the code 0 resource
generated by the Pila, the "Application Global" size is 0, and the size
above A5 is set to the size of the Pila program's data segment. In other
words, Pila programs have their data segment above A5, instead of below it.
Does the fact that the data segment for Pila-compiled programs is located
where the "jump table" and "application parameter" section cause any
problems? Yes, although Pila has a workaround that apparently works for
PalmOS 1.0 and 2.0. Currently, the PalmOS loader stores a pointer to the
application's SysAppInfo at the beginning of the applications parameter
section --- that is, at the four bytes starting at the A5 register. Some of
the PalmOS ROM routines depend on this pointer being present. To avoid
overwriting it, Pila's startup routine reserves four bytes of space at the
beginning of the segment, and when Pila constructs the compressed Data
segment, it is set up to start decompressing starting at an offset four bytes
beyond the A5 register.
One useful data point which we can infer from Pila's non-standard memory
module is that only the first four bytes of memory above the A5 register
currently appear to be in use. Otherwise, Pila compiled programs would likely
cause some kind of crash or Pilot malfunction. Apparently the rest of the 32
bytes reserved by the Metrowerks compiler for "Application Parameters" is
reserved for future expansion, but is not being used now. In addition, since
some Pila-compiled programs have data segments greater than 32 bytes, this
also confirms our theory that the jump table is also currently not being
used.
This raises a cautionary note that while Pila-compiled programs work now,
they may fail in the future if later versions of PalmOS use additional
memory above the A5 register beyond the first four bytes. The PalmPilot
Developer Technical Brief explicitly warns that "If your application was not
developed with the Metrowerks CodeWarrior for Pilot, it may run into
problems."
Developers would do well to heed this warning, especially in the case of
Pila where it is using a radically different memory model where the data
segment of the assembly language program is overloading memory space
reserved for application preferences and for the jump table.
þ The Code #1 resource
This resource contains the actual code for the application. For some reason,
PRC executables generated by the Metrowerks compiler have the a four-byte
word 0x00000001 (ori.b #1, %d0) at the beginning of the code resource. The
obj-res program duplicates this behaviour, although Pila does not, and it
doesn't seem to make a difference.
It is not clear whether the four byte word is meant to a flag or bitfield,
or whether it is some other kind of signal. When PalmOS starts executing the
application, it obviously starts at beginning of code segment #1. To test to
see if the initial four byte word was intended to be interpreted as a
instruction, I tried replacing it with a rts instruction. This test made it
clear that the ori.b #1, %d0 instruction is actually executed. However, this
instruction doesn't appear to do anything useful. It merely sets the low bit
in data register 0; however, data register 0 is never used until it is later
re-initialized.
þ The Data Resource
Resource of the data - probably most mysterious resource, it almost do not
describe and if describe that It is not enough and almost nothing can be
understood from these explanations. Plenty of the information I has taken at
The author Pila of the compiler "Darrin Massena", one of the conducting
programmers under PalmPilot.
The major purpose of the data resource is to initialize global variables.The
data resource can also contain relocation tables to handle arrays containing
pointers to static data (for either constant data stored in the code 1
segment, or writeable data which is stored in the data resource). The
high-level format of the data resource is:
Ö--------Â------·
º offset | size º þ Data Resource
Ç--------Å------¶
º 0 | 4 º ù offset of CODE 1 xrefs (4+n+m)
º 4 | n º ù compressed global initializers
º 4+n | m º ù compressed DATA 0 xrefs
º 4+n+m | p º ù compressed CODE 1 xrefs
Ó--------Á------½
The compressed global initializer section contains the following
substructure repeated three times:
ù A5 offset (4 bytes), which specifies the destination where the
uncompressed data should be written.
ù Compressed stream, in blocks
ù ASCII 0 (separator).
This flexible structure allows up to three contiguous regions of the
application's A5 world be initialized with compressed data. If the
flexibility is not needed, one or more of these initializer substructures
may be replaced by 5 nulls (4 nulls for the A5 offset and one ASCII null to
indicate the lack of compressed blocks).
The Pilot uses an enhanced RLE scheme for its compressed stream. The
compressed stream contains a series of RLE blocks, followed by a zero byte
to terminate the compressed stream.
Forgive but I do not know under what circuit code RLE algorithm for me it is
a riddle.
þ Code 1 XREF and Data 0 XREF sections
About these section I in general do not know, I would be glad to receive
though what be the small information on it...
------´ Last Word Ã---------------------------------------------------------
Having read there is a lot of articlees for me and there were a riddle some
things in PRC files. Probably company letting out mini - computers Palm has
not wanted to describe these things.
Thank I read by all who to me helped, all author of articless to which about
Palm and mine to the friends and still certainly to my girlfriend which I
very much love.
Thank you read to you for that that it crazy articles.
Thanx: MATRiX TeAm, iKx TeAm
Moscow 12:11 Tuesday, 11 October 2000
email : ultras_@hotmail.com
url : www.coderz.net/ultras
irc : undernet #virus, #vir, efnet #virus, #coders.ru
ULTRAS [MATRiX]
