Hello trid users,
some days ago i handled WordPerfect files with name extension CBT. So i
looked for other WordPerfect samples. There exist samples with IRS file name
extension and names like: STANDARD.IRS
I found no information especially about file format specification about such
WordPerfect files, but luckily some basic info are found in unofficial
WordPerfect File Format description WPFF_DocumentStructure.htm. So i choose
that page as reference. That is expressed by line like:
<RefURL>
https://github.com/OneWingedShark/WordPerfect/blob/master/ doc/SDK_Help/FileFormats/WPFF_DocumentStructure.htm
</RefURL>
When i run TrID on such examples these are described correctly but
unspecific like "WordPerfect (generic)" by definition wp-generic.trid.xml
(see appended output/trid-v-old.txt).
For comparison reason i also run the file utility (version 5.42). This
describes the examples as "Corel WordPerfect" with sub classification as
"filetype 42" and version "v5.0" (see appended output/file-5.42.txt).
In the unofficial documentation file type 42 (0x2A) is listed and this is
called here "Mouse driver for WP5.1". Furthermore i looked how other call
IRS samples. I found something like "Corel WordPerfect IRS resource file" or
" Resource (WordPerfect) standard.irs - WordPerfect". So i choose what
seems to be average of the descriptions. So i express this inside TrID
definition by lines like:
<FileType>WordPerfect Resource</FileType>
<Ext>IRS</Ext>
When looking inside sample i found strings like "Mouse Driver
(MOUSE.COM)". So i know that this classification is alright.
So i run tridscan on example to generate ins-wp.trid.xml. So we see that not
only the first 4 bytes are the same like \xFFWPC that is generic for all
WordPerfect samples, but also the first bytes are the same. That is
expressed by XML construct like:
<Bytes>FF57504310000000012A000000000000E60FD38DC00F13005E008B
<ASCII> . W P C . . . . . * . . . . . . . . . . . . . . ^</ASCII>
<Pos>0</Pos>
Unfortunately the definition is based only on 1 sample. At offset 4 pointer
to document area is stored as 4 byte little endian integer. In my example
this value was 42 ( hexadecimal 2A). So the 3 upper bytes are nil by lucky
circumstances in my examples. At offset the 8 and 9 the product and file
type are stored. In my example this value was always 1 and 20 ( hexadecimal
14). That is significant for WordPerfect resource for Mouse driver files
according to documentation. At offset 10 the major version and minor
version fields are stored as byte value. In my examples this value was v5.0
( hexadecimal 0000). Assuming that there exist examples with other document
area offset and other version numbers this becomes according to
documentation like:
<Pattern>
<Bytes>FF575043</Bytes>
<ASCII> . W P C</ASCII>
<Pos>0</Pos>
</Pattern>
<Pattern>
<Bytes>012A</Bytes>
<Pos>8</Pos>
</Pattern>
At offset 12 encryption field is stored. In my examples this was always
zero. At offset 14 pointer to index area is stored. In my examples this
value was always zero. At offset 16 not documented extended header
starts. In my examples this value always starts with byte sequence
e60fd38dc001300. But i do not know if this always true. So i delete these
parts concerning patterns.
With the new definition now WordPerfect Resource IRS example is described
more precisely ( see appended output/trid-v-new.txt). TrID definition and
output are stored in archive irs_.zip. I hope that the XML file can be used
in future version of triddefs.
With best wishes
Jörg Jenderek
