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 DRS file name
extension and names like: WPSMALL.DRS
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
"driver resource data" and version "v3.3" (see appended
output/file-5.42.txt).
In the unofficial documentation for DRS file type 20 (0x14) is listed and
this is called here "Display resource file". Furthermore i looked how other
call DRS samples. I found something like " Corel WordPerfect driver
resource" or "Display Resource file". So i choose what seems to fit best
the file name suffix. So i express this inside TrID definition by lines
like:
<FileType>WordPerfect Display Resource</FileType>
<Ext>DRS</Ext>
When looking inside sample i found strings like "Courier", "Helvetica"
"COU00EGA.BIN". So i know that this classification is alright.
So i run tridscan on example to generate drs-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>FF575043460000000114030300000000</Bytes>
<ASCII> . W P C 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 70 ( hexadecimal 46). 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 Video Resource DRS 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 v3.3 ( hexadecimal
0303). 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>0114</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
46000000. So this is the same as document pointer. But i do not know if
this always true. So i delete these parts concerning patterns.
With the new definition now WordPerfect WordPerfect Display Resource DRS
examples are described more precisely ( see appended
output/trid-v-new.txt). TrID definition and output are stored in archive
drs.zip. I hope that the XML file can be used in future version of triddefs.
With best wishes
Jörg Jenderek
