ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ 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]