If the brother link in the application front DOR is not set to zero it is taken as pointing to a help front DOR. The help front DOR looks like this:
3 bytes 0 0 0 Link to parent
3 bytes 0 0 0 Link to brother
3 bytes x x x Link to son, this points to the first Help DOR
1 byte $13 DOR type, application Front DOR
1 byte 8 DOR length
1 byte 'N' Key for name field
1 byte 5 Length of name and terminator
5 bytes 'HELP', 0 NULL-terminated name
1 byte $FF DOR terminator
A help DOR entry looks like an application DOR entry, but without the information record:
3 bytes 0 0 0 Link to parent
3 bytes x x x Link to brother (points to another Help DOR or set to
zero)
3 bytes 0 0 0 Link to son
1 byte $83 DOR type, application ROM
1 byte x total DOR length
1 byte 'H' Key to help section
1 byte x Length of help section
3 bytes x x x Extended pointer to topics
3 bytes x x x Extended pointer to commands
3 bytes x x x Extended pointer to application help
3 bytes x x x Extended pointer to token base.
1 byte 'N' Key to name section
1 byte x Length of name
x bytes 'xxxx',0 Null-terminated application name. Must be the name of
an existing application.
1 byte $FF DOR terminator byte.
The Help in a Help DOR takes priority over the Help in the application DOR, but for ROM applications it is not necessary to use a separate DOR. The use of the Help DOR is mainly in providing Help for internal applications or applications in other ROM cards. If you intend to provide Help for an internal application you will need to provide all the same command codes for the commands. Therefore, it will be necessary to examine the structure of the internal application carefully. This is readily achieved by opening the application with GN_Opf and A = OP_DOR to get a DOR handle, and reading the addresses of the Help structures out of the Help record. The application name can be retrieved by letting FILER provide the filename: try listing all application names with the ":ROM.*//*" wildcard.