Using ChkINF with Modem INF Files
Use the INF File Syntax Checker (ChkINF) to check the syntax and content of a modem INF file. This topic provides general information about using ChkINF, including how to handle certain error messages. This topic also supplements the complete instructions that are included with ChkINF.
Always include all possible responses for your modem in your INF file. Do not include responses that the modem cannot actually provide. Use your modem documents and firmware to determine the actual responses that you should put in the INF file. ChkINF might respond with a large number of warnings about missing INF file response entries. These warnings point out cases that you might have overlooked and should only be taken as reminders.
ChkINF warns about PCMCIA card tuple hardware IDs of more than 50 characters. This warning can be ignored in Windows 2000 and later versions of the operating system. If you need to support older Windows versions, consider shortening your tuple if you do not require the extra length. Do not confuse this issue (tuple ID length) with a long friendly string.
The following INF file entry will generate an error in ChkINF:
HKR, Responses, "RINGING", 1, 01, 00, 00,00,00,00, 00,00,00,00 ;(E3117) The response contains no keyword for the state 0x01 (Negotiation Progress).
Assuming that your modem supports the RING and RINGING responses, the Responses INF file entries should have the bResponseState byte set to 0x08 as shown in the following examples:
HKR, Responses, "RING", 1, 08, 00, 00,00,00,00, 00,00,00,00 HKR, Responses, "RINGING", 1, 08, 00, 00,00,00,00, 00,00,00,00
In this example, ChkINF warns about the following response entry:
HKR, Responses, "<cr><lf>NO CARRIER: HEADSET<cr><lf>", 1, 04, 00, 00,00,00,00, 00,00,00,00 ;(E3117) The response contains no keyword for the state 0x04 (No Carrier).
The ChkINF lookup table does not contain information about the response. Verify that the correct bResponseState for your modem is indicated in the Responses entry. In this example, the modem is not connected, and an error has occurred. Therefore the Responses entry is correct. In this event, attach a note with your submission to WHQL to make them aware of the ChkINF issue.
ChkINF generates a warning in response to the following INF file entry:
HKR, Responses, "<cr><lf>CONNECT<cr><lf>", 1, 01, 00, 00,00,00,00, ff,01,00,00
Two errors are present in this example:
The bResponseState byte is set incorrectly for a connect message.
In addition, the last DWORD (dwNegotiatedDTERate) should not be used.
The correct response entry is as follows:
HKR, Responses, "<cr><lf>CONNECT<cr><lf>", 1, 02, 00, 00,00,00,00, 00,00,00,00
Note The dwNegotiatedDTERate data field should rarely be used. For modems that support only direct modes, it is possible to direct Unimodem to lower its DTE speed by specifying a value for dwNegotiatedDTERate. This is not usually needed because most modems make connections with automatic speed buffering.
It is possible to create errors by cutting and pasting from an old INF file. Obsolete voice INF files had TerminateRecord settings ending in "AT<cr>" as shown in the following example:
HKR,, TerminateRecord,, "<h10>E<cr>at<cr>" ;(W4040) Command "TerminateRecord" should not terminate in AT<cr>.
Use the following INF file entry instead:
HKR,, TerminateRecord,, "<h10>E<cr>"
The following warning messages all require a similar fix:
;(W4040) Command "TerminateRecord" should not terminate in AT<cr>. ;(W4040) Command "TerminatePlay" should not terminate in AT<cr>. ;(W4040) Command "AbortPlay" should not terminate in AT<cr>.
ChkINF generates a warning message about the mixer chipsetting in the VoiceProfile entry as follows:
HKR,, VoiceProfile, 1, 27,03,08,00 ;(W4052) Separate sound mixer chip required.
This message is a reminder to verify the correct mixer chipsetting. Ignore this message if you have verified the correct mixer chipsetting.