Share via

6 Appendix A: Product Behavior

  • Article

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

  • Windows NT operating system

  • Windows 2000 operating system

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

  • Windows 10 operating system

  • Windows Server 2016 operating system

  • Windows Server 2019 operating system

  • Windows Server 2022 operating system

  • Windows 11 operating system

  • Windows Server 2025 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.5: The DirectPlay 4 Protocol is available only in Windows operating systems that have the DirectX 6 runtime (from the DirectX 6 Software Development Kit (DirectX SDK)), or later version of the runtime installed. All Microsoft products that are identified as applicable to this protocol in section 6 of this specification meet this requirement.

<2> Section 1.7: The following DirectPlay 4 dialects are natively included in Windows operating systems: DX71VERSION (supported only in Windows 2000), DX8VERSION (supported only in Windows XP and Windows Server 2003), and DX9VERSION (not supported in Windows NT, Windows 2000, and Windows XP).

An operating system service pack or out-of-band DirectX redistributable can upgrade the native dialect to a later version. The maximum version to which a dialect can be upgraded is DX9VERSION.

The DirectX Software Development Kit (DirectX SDK) provided multiple programming interfaces with names such as IDirectPlay4 and IDirectPlay3, but these do not affect the wire protocol. All interfaces implement the DirectPlay 4 Core and Service Provider Protocol according to the native or upgraded dialect associated with the operating system.

<3> Section 2.2.3: If the Windows Winsock DirectPlay Service Provider is used, the SL field is set to 0x1 in the PlayerInfoMask field, and the ServiceProviderDataLength field is set to 0x20.

<4> Section 2.2.4: Windows sets the Size field to 0.

<5> Section 2.2.4: An implementation supports at least one of the values shown in the following table.

Algorithm

Description

OS versions exceptions

Reference

CALG_AES

0x00006611

Advanced Encryption Standard (AES). This algorithm is supported by the Microsoft AES Cryptographic Provider.

Not supported in Windows NT, Windows 2000 and Windows XP. Supported in Windows XP operating system Service Pack 1 (SP1)

[FIPS197]

CALG_3DES

0x00006603

Triple Data Encryption Standard (DES) encryption algorithm (3DES).

Not supported in Windows NT and Windows 2000

For more information, see the entry for [TDEA] in section 1.2.1.

CALG_DES

0x00006601

Data Encryption Standard (DES).

Not supported in Windows NT

[FIPS46-2] and [FIPS46-3]

CALG_RC2

0x00006602

Rivest Cipher 2 (RC2) block encryption algorithm. This algorithm is supported by the Microsoft Base Cryptographic Provider.

None

[RFC2268]

CALG_RC4

0x00006801

RC4 stream encryption algorithm. This algorithm is supported by the Microsoft Base Cryptographic Provider.

None

[SCHNEIER], section 17.1

For more information about these encryption algorithms, see [MSDN-ALG_ID].

Implementations might choose to support other algorithms and values not shown here; if they do, they reuse the values specified in [MSDN-CRYPTO] to avoid collisions.

<6> Section 2.2.5: When the OL flag is present, Windows disables the Nagle algorithm for its TCP sockets.

<7> Section 2.2.5: Windows does not initialize the SessionName field to zero when sending; the receiver must ignore the data.

<8> Section 2.2.5: Windows does not initialize the Password field to zero when sending; the receiver ignores the data.

<9> Section 2.2.28: In Microsoft Windows, the ShortcutCount field is uninitialized when sent.

<10> Section 2.2.48: Windows implementations can send nonzero values for the X bitfield.

<11> Section 3.1.1: In Windows, the only supported value for Game.SSPIProvider is NTLM.

<12> Section 3.1.1: In Windows, the Game.CAPIProvider is one of the following cryptographic provider names.

  • Microsoft Base Cryptographic Provider v1.0

  • Microsoft Enhanced Cryptographic Provider v1.0

  • Microsoft RSA Signature Cryptographic Provider

  • Microsoft Base RSA SChannel Cryptographic Provider

  • Microsoft Enhanced RSA SChannelStrong Cryptographic Provider

  • Microsoft Base DSS Cryptographic Provider

  • Microsoft Base DSS and Diffie-Hellman Cryptographic Provider

  • Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider

  • Microsoft Base DH SChannel Cryptographic Provider

  • Microsoft Enhanced DH SChannel Cryptographic Provider

  • Microsoft Base Smart Card Crypto Provider

<13> Section 3.1.1: In Windows, the Game.CAPIProviderType value is one of the following values.

  • PROV_RSA_FULL (0x00000001).

  • PROV_RSA_SIG (0x00000002): The PROV_RSA_SIG provider type is a subset of the PROV_RSA_FULL type, it only provides support for hashes and signatures using the RSA signature algorithm.

  • PROV_DSS (0x00000003): The PROV_DSS provider type is a subset of the PROV_RSA_FULL type; it only provides support for hashes and signatures using the DSS signature algorithm.

  • PROV_FORTEZZA (0x00000004): The PROV_FORTEZZA provider type specifies cryptographic protocols and algorithms specified by the National Institute for Standards and Technology.

  • PROV_MS_EXCHANGE (0x00000005): The PROV_MS_EXCHANGE provider type is intended for the needs of Microsoft Exchange.

<14> Section 3.1.1: An implementation supports at least one of the values shown in the following table.

Algorithm

Description

OS versions exceptions

Reference

CALG_AES

0x00006611

Advanced Encryption Standard (AES). This algorithm is supported by the Microsoft AES Cryptographic Provider.

Not supported in Windows NT, Windows 2000 and Windows XP. Supported in Windows XP SP1

[FIPS197]

CALG_3DES

0x00006603

Triple DES encryption algorithm (3DES).

Not supported in Windows NT and Windows 2000

For more information, see the entry for [TDEA] in section 1.2.1.

CALG_DES

0x00006601

DES Encryption Standard (DES).

Not supported in Windows NT

[FIPS46-2] and [FIPS46-3]

CALG_RC2

0x00006602

RC2 block encryption algorithm (RC2). This algorithm is supported by the Microsoft Base Cryptographic Provider.

none

[RFC2268]

CALG_RC4

0x00006801

RC4 stream encryption algorithm (RC4). This algorithm is supported by the Microsoft Base Cryptographic Provider.

none

[SCHNEIER], section 17.1

For more information about these encryption algorithms, see [MSDN-ALG_ID].

Implementations can choose to support other algorithms and values not shown here; if they do, they reuse the values specified in [MSDN-CRYPTO] in order to avoid collisions.

<15> Section 3.1.2.1: If no application-defined timer has been set, Windows uses a default timer value of 5 seconds.

<16> Section 3.1.4.16: In DirectPlay library implementations for Windows platforms, encryption and signing services are provided by the Windows platform APIs.

<17> Section 3.1.4.16.2: In Windows, if the DirectPlay client is using the DirectPlay Winsock Service and the higher level did not specify guaranteed delivery, then the datagram (UDP) or message (TCP) is sent over the protocol (UDP or TCP, respectively) to the socket address associated with the target player.

<18> Section 3.1.5.1: In Windows, the only SSPI provider supported is "NTLM".

<19> Section 3.1.5.5: Windows returns a DPERR_LOGONDENIED error code to the caller when this message is received.

<20> Section 3.1.5.10: If the Windows Sockets DirectPlay provider is used, the SpData field of the DPSP_MSG_ADDFORWARD request contains the IP address and port number that are used to communicate with the system player.

<21> Section 3.2.5.4: In Windows, the only supported SSPI provider is the NTLM SSPI provider which implements the NT LAN Manager (NTLM) Authentication Protocol, as specified in [MS-NLMP].

<22> Section 3.2.5.5: If the service provider is the Windows Winsock DirectPlay Service Provider, then the DPSP_MSG_ADDFORWARD message contains the IP address of the sender of the DPSP_MSG_ADDFORWARDREQUEST message and the port number contained in the DPSP_MSG_HEADER.SockAddr field (section 2.2.6).

<23> Section 5.1: DirectPlay actually provides access to end-to-end secure identity using Windows NT security, and it provides for packet encryption and signing. For secure operation, employ that mode.