Registry Entries for Clients Running Windows 95

The following list gives details about Windows 95 registry entries for clients running Windows 95. For each TP type, the applicable variables and their locations are shown in Clients Running Windows 95.

SNAServiceType:REG_DWORD:{ 0x5 | 0x6 | 0x1A }

Indicates the type of TP. Use a value of 0x5 for an autostarted queued TP, 0x6 for an autostarted nonqueued TP, and 0x1A for an operator-started TP.

PathName:REG_EXPAND_SZ:path

For an autostarted TP running as an application, specifies the path and file name of the TP. The data type of REG_EXPAND_SZ means that the path can contain an expandable data string; for example, %SystemRoot% represents the directory containing the Windows 95 system files.

LocalLU:REG_SZ:LUalias

Specifies the alias of the local LU to be used when this TP is started on this computer.

Parameters:REG_SZ:ParameterList

Lists parameters to be used by the TP. Separate parameters with spaces.

Timeout:REG_DWORD:number

Specifies the time, in milliseconds, that an Accept_Conversation will wait before timing out. Specify number in decimal; the registry editor converts this to hexadecimal before displaying it. The default is infinity (no limit).

AcceptNames:REG_SZ:TPNameList

With Windows 95, used for autostarted TPs only; lists additional names under which the invokable TP can be invoked. Separate TP names with spaces. The default is none. If an invokable TP does not issue a Specify_Local_TP_Name for each name configured under AcceptNames in the registry, that TP will fail.

ConversationSecurity:REG_SZ:{ YES | NO }

Indicates whether this TP supports conversation security. The default is NO.

AlreadyVerified:REG_SZ:{ YES | NO }

Indicates whether this TP can be invoked with a user identifier and password that have already been verified. AlreadyVerified is ignored if ConversationSecurity is set to NO.

For a diagram of three TPs in a conversation, where the third TP can be invoked with a password that is already verified by the second TP, see Communication Between TPs. The following table shows the requirements for using password verification in a chain of TPs.

First TP (an invoking TP) Second TP (invokable TP that confirms password and then invokes another TP)

Third and subsequent TPs (invokable TPs that invoke other TPs)

Does not need registry or environment variables.

ConversationSecurity setting must be YES. ConversationSecurity setting must be YES.

Does not need registry or environment variables.

AlreadyVerified setting can be YES or NO. AlreadyVerified setting must be YES.

Symbolic destination name or Set_Conversation_
Security_Type in this TP specifies PROGRAM for the security type; as a result, the TP passes along the user identifier and password supplied in the symbolic destination name (or through calls1). Symbolic destination name or Set_Conversation_
Security_Type in this TP specifies SAME for the security type; as a result, after confirming the user identifier and password, the TP passes along the user identifier and an already-verified flag. Symbolic destination name or Set_Conversation_
Security_Type in this TP specifies SAME for the security type; as a result, the TP passes along the user identifier as received, along with the already-verified flag.

First TP (an invoking TP)	Second TP (invokable TP that confirms password and then invokes another TP)	Third and subsequent TPs (invokable TPs that invoke other TPs)
Does not need registry or environment variables.	ConversationSecurity setting must be YES.	ConversationSecurity setting must be YES.
Does not need registry or environment variables.	AlreadyVerified setting can be YES or NO.	AlreadyVerified setting must be YES.
Symbolic destination name or Set_Conversation_ Security_Type in this TP specifies PROGRAM for the security type; as a result, the TP passes along the user identifier and password supplied in the symbolic destination name (or through calls1).	Symbolic destination name or Set_Conversation_ Security_Type in this TP specifies SAME for the security type; as a result, after confirming the user identifier and password, the TP passes along the user identifier and an already-verified flag.	Symbolic destination name or Set_Conversation_ Security_Type in this TP specifies SAME for the security type; as a result, the TP passes along the user identifier as received, along with the already-verified flag.

Note:

1 Set_Conversation_Security_User_ID or Set_Conversation_Security_Password will overwrite the user identifier and password specified in the symbolic destination name.

If you set AlreadyVerified to NO, this TP cannot join in a chain of conversations where password verification is already done. (The exception to this is when ConversationSecurity is set to NO, in which case the TP could be the final TP in such a chain, since it performs no checking.)

If you are configuring a TP that sometimes needs to confirm a password and sometimes accepts an already-verified flag, set AlreadyVerified to YES and configure the UsernameX variable appropriately. In this case, whenever the TP is invoked without the already-verified flag set, AlreadyVerified is ignored; verification is attempted with the user identifier and password configured for the TP.

The default for AlreadyVerified is NO. If you set AlreadyVerified to YES, make sure that ConversationSecurity is also set to YES.

Username1:REG_SZ:Password1 ... UsernameX:REG_SZ:PasswordX: Sets one or more user names and passwords to be compared with those sent by the invoking TP. The user name and password can each be as many as 10 characters. Both parameters are case-sensitive.
This variable is ignored if conversation security is not activated or if the password has already been verified, as described for the AlreadyVerified entry.