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 FIL file name
extension and names like: WP.FIL
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 21" and version "v3.0" (see appended output/file-5.42.txt).
In the unofficial documentation file type 21(0x15) is listed for WP.FIL and
this is called here "Overlay file". Furthermore i looked how other call FIL
samples. I found something like "Corel WordPerfect overlay data", "Overlay -
WordPerfect" or "WordPerfect Overlay (Corel Corporation)". So i choose what
seems to be average of the descriptions. So i express this inside TrID
definition by lines like:
<FileType>WordPerfect overlay</FileType>
<Ext>FIL</Ext>
So i run tridscan on example to generate fil-wp-overlay.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>FF5750431000000001150300000000004F3C6613000000000000000000000000</Bytes>
<ASCII> . W P C . . . . . . . . . . . . O . f</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 16 ( hexadecimal 10). 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 21 ( hexadecimal
15). That is significant for WordPerfect overlay file (WP.FIL) according to
documentation. At offset 10 the major version and minor version fields are
stored as byte value. In my examples this value was v3.0 ( hexadecimal
0300). 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>0115</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
ff5750431000. But i do not know if this always true. So i delete these parts
concerning patterns.
With the new definition now WordPerfect overlay FIL example is described
more precisely ( see appended output/trid-v-new.txt). TrID definition and
output are stored in archive fil_overlay.zip. I hope that the XML file can
be used in future version of triddefs.
With best wishes
Jörg Jenderek
