The CHS format consists of an 80 byte header:
| Offset | Type | Comment/Value |
| 0 | BYTE[4] | 79 56 34 12 (signature) |
| 4 | DWORD | 0 (unknown) |
| 8 | DWORD | Number of subset entries (could also be QWORD, or even WORD or BYTE). |
| 0xC | DWORD | 0 (unknown) |
| 0x10 | BYTE[51] | Name of the currently selected subset or "(Entire Collection)" if no subset is selected |
| 0x43 | BYTE[13] | Unknown. May be a timestamp(s) or junk data. |
… followed by the subset entries repeated to the end of the file:
| Offset | Type | Comment/Value |
| 0 | DWORD | Number of DWORDs at the end of the entry. Length of each entry = 4*this+112 |
| 4 | BYTE[51] | Name of the subset. ANSI NT string. After the NIL terminator the rest of the 51 BYTEs are filled with garbage. This should not be "New" or "(Entire Collection)" since some fugly bugs will result. |
| 0x37 | BYTE[57] | Unknown. Seems to be an ANSI NT string that is an abbreviation of some kind - eg VC, MSDN, VSS etc |
| 0x70 | DWORDs | Subset contents info (unknown format - each DWORD represents a single leaf node, they are unique within a collection & they don't seem to change if you delete the CHS & recreate the subset). Please let us know if you figure out how these DWORDs specify which CHMs to use. |
Ensure that the number of subsets as stored in the header is not greater than the actual number of subset entries in the file, since on Win95 at least HH will not open the HH viewer, but cause a lot of disk activity & crash/freeze Win95.