The last command is followed by a data structure. There are two types of such "trailers", one for Winplan, one for DOS.

The structures are addressed from the end of the file (i.e., `Seek(F, FileSize(F) - N)', that's why it's deadly to enlarge a TRN file. If the checksums don't match, Host tries to recover from a X-Modem transfer (which appends Ctrl-Z to files) by removing Ctrl-Z's. Windows TRNs with appended Ctrl-Z's are no longer recognized as such.

Structure for VGA Planets for DOS

 +0     DWORD   Checksum `X'
 +4     DWORD   Contains random data with original MAKETURN. Some
                MAKETURNs put a signature here.
 +8 204 BYTEs   Signature from FIZZ.BIN (offset 136, the 2 strings + sum)
+212 11 DWORDs  Id block (see below)

The checksum `X' is the sum of all bytes in the TRN file up to (but not including) this structure, plus 3 times the timestamp checksum, plus 13.

If the TRN file doesn't contain any command, this block is located at position 28 in the file.

Winplan Shareware is identical to DOS planets from this point of view and generates the same file format.

Structure for Winplan registered

 +0   6 BYTEs   Signature "VER3.5"
 +6   2 BYTEs   Sub-version "00", "01"...
 +8     DWORD   VPH35 Value, part A
+12     DWORD   VPH35 Value, part B
+16  25 BYTEs   String 1, part A (Serial number)
+41  25 BYTEs   String 1, part B
+66  25 BYTEs   String 2, part A (Registration date)
+91  25 BYTEs   String 2, part B
+116 50 BYTEs   String 3 (Name of player)
+166 50 BYTEs   String 4 (Address of player)
+216 100 BYTEs  ??? (zero)
--- the DOS structure follows here ---
+316    DWORD   Checksum `X'
+320    DWORD   Contains random data with original MAKETURN. Some
                MAKETURNs put a signature here.
+324 204 BYTEs  Signature from FIZZ.BIN (offset 136, the 2 strings + sum)
+528 11 DWORDs  Id block (see below)

Checksum `X' is computed the same way as in DOS TRNs: up to (but not including) the DOS structure. The first 316 bytes are part of this checksum!

The Strings 1 and 2 give the exactly the same text as in FIZZ.BIN. Here, they are encoded as

    Character[i] := ( PartA[i] XOR PartB[i] )

String 1 is interpreted as a serial number, 2 as registration date. The strings 3 and 4 appear "as is" in REG.LOG, they are unencoded. They are the name and address the user entered when unlocking his Winplan copy.

Both DWORDs at position 8 and 12 give a value `Y':

Y = ( VPHValue_A XOR VPHValue_B ) AND 7FFFFFFFh

This equals the record `VPH_Record(Turn_Number)' from VPH35.DLL, see there. The values actually written to the TRN file come from SCRAM21.OLE, a file with the same information encoded in a different way.

While THost also accepts unregistered TRNs with Windows trailer, and answers with Windows RSTs, PHost evaluates the Windows trailer only for registered clients: there is no unregistered Wisseman client which generates Windows TRNs. However, PCC can do this.

Id Block

The Identification block at the end of a TRN file allows a player to play several races with one registered client program. If 2 TRN files were generated by the same program, they contain the same registration signature and the same Id Block.

With MAKETURN.EXE, the Id block contains 11 DWORDs. Each of these 11 entries is the checksum `X' from the respective player's TRN file, or zero if that player was not processed by this MAKETURN invocation. For some unknown reason, player 11's position when he does not play is 0F31h.

Winplan puts the respective game's SNOOKER.DAT entry here.

The actual values put here do not really matter. All you must make sure that TRNs made for the same game from the same computer bear the same 11-DWORD block. With current hosts, there is no requirement for the Id block to be derived from the TRN file contents in any way, like DOS MAKETURN generates it. The really only requirement is that TRN files from the same registered copy bear the same block. Older PHosts (3.15.1.x) required the DOS-Planets behaviour (entry N = player N's checksum `X'), and thus could not be used with Winplan.