WinSock 2 Feature Status - UNDER CONSTRUCTION

April 18, 1997 BQ NOTE: Still Needs some more updates in light of Win95 update!

Return to Sockets.com WinSock 2 page

Here is a list of the WinSock 2 Feature categories for which I provide detailed status here. Eventually, I'll also include source code for the test programs I use to test these features. They are somewhat unsanitary at this point, and none are flashy (just functional).

I'd appreciate feedback on anything covered here, and I'd particularly like to hear if you have any corrections to make. Thanks, and good luck!.

These status are from WinSock 2 from NT Server version 4.0 (Service Pack 3), and the "final release" (June '97) for Windows 95 from the WinSock 2 SDK (NOTE: I know that some of the bugs reported here have been remedied in the WinSock 2 update for Win95 released 2/28/98, but I have not had a chance to test them all or update this page yet).

Disclaimer: I've done my best to test everything here according to my reading of the WinSock 2 specifications. In some cases, especially when functions fail with the non-descriptive error WSAEINVAL (10022), I am left wondering if perhaps I'm doing something that isn't quite right to cause the failure. This was the case for a while with my use of the setsockopt() IP_TTL and IP_OPTIONS. However, on the other hand, there are options that I know don't work, that fail with WSAEINVAL (namely, WSAIoctl() SIO_TRANSLATE_HANDLE and SIO_ASSOCIATE_HANDLE), so it's difficult to know for sure. Hence, the title will indicate UNDER CONSTRUCTION until I have indesputable test results.

[Go to top]

Generic Issues

This section covers some general issues that don't relate to any specific WinSock 2 feature(s), but to WinSock 2 in general..

WinSock 2 is indeed an important update to the WinSock API as it has a number of features that are important to future network applications, the most significant of which is clearly the architecture that supports multiple protocols simultaneously. But in all honesty, in many respects WinSock 2 isn't fully baked yet. There are a number of sugnificant issues still unresolved, some of the prominent features are not implemented yet, and there are many problems with some of the new stuff that is implemented. Here is a list of some of the outstanding issues and uimplemented features:

[Go to top]

Multiple Protocol Support

This refers primarily to the new WinSock 2 "Windows Open System Architecture" (WOSA) in which service providers install their modules "beneath" the WinSock 2 DLL (WS2_32.DLL). Unlike WinSock 1.1 DLLs, WinSock 2 DLLs are owned maintained by Intel and Micorosft, not by the Service Provider.

This relates to a number of subjects:

In addition to these issues, Layered Service Providers (LSPs) really belongs under this topic. However, since LSPs have so many issues of their own, I've put them under a seperate heading here.

WinSock 1.1 compatibility

One might consider that WinSock 1.1 compatibility is related to this issue. The differences between WS2 and WS11, apart from the new features in WS2, are minimal. They are limited to WSAStartup()'s WSAData structure, and the lack of support for blocking hook related functions (e.g. WSAIsBlocking(), WSACancelBlocking(), WSASetBlockingHook(), and WSAUnhookBlockingHook()). The only other issue that I've run into is the need to re-order the WINSOCK2.H and WINDOWS.H files, in sources that contain both (if WINDOWS.H is included before WINSOCK2.H, the compile with MSVC 4 will fail with the "redefinition: different linkage" errors for WinSock function calls).

Installation Issues

Most of the big installation issues are involved with Layered Service Providers, and discussed elsewhere in the WinSock 2 pages of this website. Other than that, I don't know of many installation issues.  To be honest, I haven't yet done a lot of testing of installation programs (other than as a user, anyway). I deal with the installation functions (with the WSC prefix) elsewhere here (in the LSP and NameSpace sections).

See the /SAMPLES/VENDINST/README.TXT file installed with the WinSock 2 SDK for information describing the API documentation, and requirements for Vendor Installation using the WinSock 2 source code provided in the same directory. This is useful not only for Service Providers, but application developers also, if they want to make sure that WinSock2 is installed properly to support their WinSock 2 application.

Unfortunately, the Vendor Installation documentation file doesn't address the issues of installation--and particularly those involved with Layered Service Provider (LSP) layering are up in the air.

Debug Trace DLL Issues

Related to the WOSA architecture is the Debug/Trace DLL (DT_DLL.DLL), that accompanies the WinSock 2 SDK (with source code). You need to replace the standard WS2_32.DLL WinSock 2 DLL to allow it to function. HOWEVER, the one that is currently available in the "final" WinSock 2 SDK (see http://www.microsoft.com/win32dev/netwrk/winsock2/ws295sdk.html) is incompatible with NT4. Hopefully Service Pack 4 for NT4 will fix this, but in the mean time, you need the symbolic WS2_DLL.DLL from the old beta1.6 WinSock SDK that *does* work with NT4.  This beta 1.6 debug WS2_32.DLL is (temporarily) available here. This is essentially a drop-in replacement for WS2_32.DLL. I recommend that you rename your existing WS2_32.DLL to save it before replacement with this debug version.

The debug/trace DLL source code that comes with the SDK simply displays each function call and return. I have a modified version that displays input and output arguments and return values, among other features. I have not enabled output for every function yet, and still have some features to enable. See README2.TXT for details on what's missing, and what's planned. Source code for my substantially updated version is available here. I welcome any updates you are willing to provide.

New API to appear in NT5

WSAProviderConfigChange(): Brand new API to be implemented in NT5 only (not Win98), that will provide notification of installation and removal of service providers. It is currently documented in the online WinSock 2 documentation.

[Go to top]

TCP/IP Protocol Specifics

In general, Microsoft's WinSock 2 TCP/IP Service Provider implementation is standard and complete (for a detailed description of the NT stack, see the Microsoft TCP/IP Implementation Details White Paper). However, there are a number of significant protocol behaviors that distinguish it--some of which are bugs--and application developers should be aware of them, since they affect the API behaviors, which means they can affect applications. In some cases, applications will have to accomodate these behaviors to operate reliably.

WSAIoctl() SIO_GET_INTERFACE_LIST: Wierd-- Works fine on Win95 with a few exceptions:

On NT4, SIO_GET_INTERFACE_LIST causes a GPF in the WS2_32.DLL with the non-debug version of WS2_32.DLL, but works fine with the debug (SDK) version of WS2_32.DLL (see Microsoft Knowledge Base Article ID: Q170642). Hopefully this will be remedied in Service Pack 4 for NT4.

NOTE: Also see the new Interface and Routing APIs.

setsockopt()

getsockopt()

IP Multicast APIs

setsockopt()

getsockopt()

Raw Sockets

The current implementations support SOCK_RAW for protocol IPPROTO_ICMP, IPPROTO_IGMP and others (e.g. RSVP, protocol 46). However, it isn't possible to provide your own IP header: the IP_HDRINCL socket option isn't supported, and with a "raw IP" socket, it sends your IP header as data (and a bogus protocol type). It also is NOT possible to receive any/all datagrams. It only allows receipt of a response after sending (actually, I only got raw sockets to receive successfully with ICMP).

As Dave Gravereaux <davygrvy@bigfoot.com> discovered, it is possible to receive many ICMP Error messages, including "Port Unreachables" by using a raw ICMP socket (e.g. socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) and calling bind() with reference to INADDR_ANY as the address. It cannot receive all ICMP datagrams, however (e.g. it doesn't see Echo Requests sent to the machine it's running on), and it tends to miss a lot of them when many are received in succession. I am still trying to qualify its limitations by testing.

NOTE: Microsoft still supports their proprietary ICMP.DLL APIs, which allow send and receipt of ICMP echo request and response datagrams, and manipulation of IP header settings. This was the only way to do pings with Microsoft WinSocks prior to their WinSock 2 release.

socket(AF_INET, SOCK_RAW, IPPROTO_IP): Wierd -- the call succeeds, but sends send your IP header as data, and send bogus IP datagrams with protocol value in IP header of zero. Receivers respond with ICMP "protocol unreachable" errors.

socket(AF_INET, SOCK_RAW, IPPROTO_RAW): Wierd -- the call succeeds, but sends send your IP header as data, and send bogus IP datagrams with protocol value in IP header of 255 (the same value for the IPPROTO_RAW macro). Receivers respond with ICMP "protocol unreachable" errors.

Also NOTE: On NT, you cannot get a raw socket unless your user has Administrator capabability. Otherwise, the socket() call fails with 10013 - WSAEACCES. This seems a severe limitation, considering that raw sockets are typically used to do simple connectivity verification via Echo-Request and Echo Response (i.e. "ping").

IPv6 - The Next Generation of Internet Protocol

Microsoft doesn't have IPv6 support, but FTP Software does, as do others (although no other WinSock 2 implementations available yet).

For more IPv6 information, see RFC 2133 (which describes the standard IPv6 sockets APIs), and http://www.ftp.com/product/whitepapers/ipv6.html, and especially http://playground.sun.com/pub/ipng/html/ipng-main.html

Open Issues

A few things that the current version of the protocol specific annex doesn't include:

[Go to top]

Layered Service Providers

Layered Service Providers represent one of the most significant new features of WinSock 2.  In effect, they provide a legitimate mechanism in the WinSock 2 architecture to transparently add services to existing protocols:

  • Sample LSP: The sample layered service provider in the WinSock 2 SDK is currently incompatible with NT version 4 because it references the new WPUCompleteOverlappedRequest() API, and the NT4 version of WS2_32.DLL doesn't have this entry point. Service Pack 4 for NT4 is supposed to fix this, but no word yet as to when it will be released. HINT: If applications fail with the error value 10106 (WSAEPROVIDERFAILEDINIT) after you install the LSP sample, the problem may simply be that the LSP.DLL is not found (since it's not in the path). Tim Moore's 11/26/97 report indicated this will be remedied in NT4 SP4 (no date for release provided). However, as Ditta Khan (FTP Software) <dittak@sol.ftp.com> reported, you can get it to work by removing the check for a valid pointer to WPUCompleteOverlappedRequest in WSPStartup() function in SPI.CPP (comment out the line "if (lpWPUCompleteOverlappedRequest != NULL)").
  • IFS Issues: Most "base" Transport Service Providers have the XP1_IFS_HANDLES service flag set in their protocol info structure, to indicate that their socket handles are equivalent to file handles (IFS stands for "installable file system"). File handle equivalency allows some special usage not available to sockets that don't have it, for example, an application can use some Win32 extensions available on NT, like completion I/O ports, and many do, including intermediate APIs and services (like RPC). The problem is that it is difficult to make an LSP that can provide IFS handles, and if it doesn't and layers over one that does, applications that expect it will fail. There have been some recent improvements made, and some new APIs defined (but not added to the spec yet) to address these issues. The most significant new addition is WPUCompleteOverlappedRequest(). For details see the Windows Sockets Service Provider Specification version 2.2.1 (released May 2, 1997 and available at the Intel WinSock 2 site, or the online WinSock 2 docs at the http://premium.microsoft.com)
  • Handle Issues: These are closely related to IFS Issues, but refer to poorly designed applications that treat a socket handle like a generic handle, so the reference them with Win32 handle APIs. This can leave an LSP "out of the loop" entirely.
  • MSWSock Issues: These issues are related to the IFS and Handle Issues. Microsoft has some proprietary WinSock-like APIs available from their MSWSOCK.DLL, many of which are used by existing middle-ware DLLs and applications. In the testing I've done, I haven't found any significant problems; most of the functions that need redirecting to the WS2_32.DLL are redirected properly. See my MSWSOCK.DLL Information page for details.
  • NameSpace Issues: Unfortunately, the WinSock 2 specification doesn't provide a way to layer NameSpace providers, although in his 11/26/97 report, Tim Moore said Microsoft would be publishing an API to do this). There is a legitimate need for this among many of the LSP developers, since--for example--many of the LSP developers that need to capture connect() calls, could be implemented more efficiently if they could capture hostname resolution calls, or they may possibly need to capture the hostnames in order to rediret connections by providing different addresses. There are many valid reasons, and no known solution other than to replace a NameSpace provider altogether, which is often not entirely feasible, and creates contention between providers trying to replace the NameSpace provider (the solution that layering of Transport service providers was intended to solve).
  • Ordering of Layered Service Providers: Dave Andersen's proposal highlights some of the issues involved with determining the layering of layered service providers (LSPs) by providing a taxonomy of LSP Service Types. Unfortunately, as is the proposal is unworkable because so many LSP implementations provide services from multiple layers, some of which are not contiguous. There is also a problem with preserving the order of LSPs, once established, among many others (e.g. authentication of LSPs, and accomodating Microsoft's new "Zero Administration Windows" architecture). Lots of hurtles to overcome.

    • WSAEnumProtocols(): Works fine - on both Win95 and NT4

    WSCDeinstallProvider(): Works fine - on both Win95 and NT4 (see Layered sample in WS2 SDK)

    WSCEnumProtocols(): Works fine - on both Win95 and NT4 (see Layered sample in WS2 SDK)

    WSCGetProviderPath(): Works fine - on both Win95 and NT4

    WSCInstallProvider(): Works fine - on both Win95 and NT4 (see Layered sample in WS2 SDK)

    NOTE: the Installation issues above are related to base service providers as well as layered service providers

    [Go to top]

    Transport Protocol Independence

    There's a subtle difference between this and multiple Protocol Support. What I'm referring to here are the APIs that an application can use to uniquely identify a protocol by it's services and operation characteristics, without ever actually knowing what protocol is in use.  This is typically done in server applications that want to offer their services on as many protocols as possible.  Typically a client will use a specific protocol within a specific address family.

    WSAEnumProtocols(): Works fine -- on both Win94 and NT4 shows all Protocol info structures, including for LSPs installed. The only protocols that are not listed are those that have the PFL_HIDDEN vendor flag set, since this flag is designed to intentionally "hide" the protocol by keeping WSAEnumProtocols() from including it in the list(though you can still access it if you know the address family, socket type and protocol 3-tuple, or the provider ID).

    getsockopt()

    setsockopt()

    WSAIoctl() SIO_GET_BROADCAST_ADDRESS: Wierd -- On Win95 fails with WSAEINVAL (10022) with all types of sockets. On NT4, it succeeds with a UDP and Raw (ICMP) sockets: It returns a buffer size of 16 bytes--the size of a SOCKADDR_IN structure--and the sin_family value is AF_INET, and sin_addr is the "limited" broadcast address of 255.255.255.255 (sin_port is zero, as one would expect). With a TCP socket, it fails with WSAEINVAL (10022). NOTE: The results do *not* change after you've called connect() to establish a default destination (which implicitly assigns a local interface). This is unfortunate, since one might hope that it would then return the local subnet broadcast address. Oh well.

    [Go to top]

    Multiple NameSpaces

    Apparently, namespace service provider related APIs are all fully implemented in the current WinSock 2 implementations. .

    WSAEnumNameSpace(): Works fine on Win95 and NT4.

    Here's what Win95 reports:

    And here's what NT4 Server (with SP3) reports:

    WSCInstallNameSpace(): Works fine on both Win95 and NT4

    WSCUnInstallNameSpace(): Works fine on both Win95 and NT4

    WSCEnableNSProvider(): Works fine on both Win95 and NT4

    [Go to top]

    Services (a.k.a., RnR) APIs

    Doesn't work for TCP/IP in general. Beware the WSAQuerySet structure settings (very fragile and cause GPFs when NULL pointers provided). See RNR sample in SDK, but beware that it deals with IPX/SPX and uses some MSWSOCK APIs. The problem with these APIs is that you need to start with a service class

    Also note the mapping macros in SVCGUID.H (which map port numbers to GUIDs), and the lack of functions.

    WSASetService: Wierd - Works for IPX on both Win95 and NT4, but a noop for TCP/IP on Win95 (although it certainly could) and on NT4 fails with Win32 error 50 : "Operation not supported"

    WSAInstallServiceClass(): not tested much, since apparently not relevant to TCP/IP (at least in the current RnR implementations)

    WSARemoveServiceClass(): not tested much, since apparently not relevant to TCP/IP (at least in the current RnR implementations)

    WSALookupServiceBegin(), WSALookupServiceNext() and WSALookupServiceEnd(): Wierd - Works on both Win95 and NT4, but don't believe what the specification tells you about what can be null fields, since WS2_32.DLL will GPF when the wrong NULL pointers are provided.  Look at the RnR sample in the WS295 SDK for clues as to what is acceptable. Also note the fact that some Service Class GUIDs are actually opcodes (e.g. SVCID_HOSTNAME, SVCID_INET_HOSTADDRBYINETSTRING, SVCID_INET_SERVICENAME, and SVCID_INET_HOSTADDRBYNAME), as listed in SVCGUID.H. All of these seem to work as advertised.

    WSAGetServiceClassInfo(): not tested much, since apparently not relevant to TCP/IP (at least in the current RnR implementations)

    WSAGetServiceClassNameByClassId(): not tested much, since apparently not relevant to TCP/IP (at least in the current RnR implementations)

    [Go to top]

    Scatter, Gather and MSG_PARTIAL

    The multiple buffer (WSABUF) input arguments for WSARecv()/WSARecvFrom() and WSASend()/WSASendto() provide support for scatter and gather operations (similar to those in the readv() and writev() functions in BSD Unix). The MSG_PARTIAL flag might also do this, but the specification isn't entirely clear what the intended use of the flag is, and current implementations don't support it (as described below).

    These operations are designed for datagram sockets that preserve message boundaries, not for stream sockets that do not (so may not fill buffers), though they do seem to work with stream sockets. The advantage that the gather operation provides is that it can assemble a single outgoing datagram from multiple buffers--e.g. put together different fields--and the scatter operation can "parse" fixed field lengths in an incoming datagram into multiple buffers.

    WSARecv()/WSARecvFrom(): Works fine -- scatters to input buffers on both Win95 and NT4 with datagram sockets. Stream sockets also work on both Win95 and NT4 SP3 in the testing I've done (which I would not recommend, since with a TCP byte stream the spec doesn't indicate that each buffer must be filled to the specified size on scatters, so behavior may be unpredictable under some circumstances with stream sockets).

    WSASend()/WSASendTo(): Works fine -- gathers from output buffers on both Win95 if you use datagram sockets. It also works with datagram sockets on NT4 SP3, although it failed with 10040 - WSAEMSGSIZE, if the message was larger than the MTU, so required IP fragmentation (e.g. greater than 1472 on Ethernet). This also works with stream sockets, but a similar warning as given for scatters goes for gathers as well (there's no guarantee that all bytes will be sent)

    MSG_PARTIAL flag for WSASend() and WSASendto(): Broken -- fails with WSAEOPNOTSUPP (10045) on both Win95 and NT4. Designed for datagram sockets to provide an effective equivalent to a "gather" operation, MSG_PARTIAL should allow you to call either function multiple times, and each successive call should append data to the outgoing data from the previous calls.

    [Go to top]

    Overlapped I/O and Event Objects

    This is fully implemented in the current WinSock 2 implementations. However, although I have listed the functions as all working fine, one qualification I'd make is with overlapped I/O on Win95. Since normally Win95 doesn't have overlapped I/O (for example, it's not available for file I/O, the way it is in NT), it is "faked." Although I haven't had any failures myself, I have heard of others having them (where overlapped I/O notification didn't occur). As a result, I'd like to raise a yellow flag here and warn anyone to test thoroughly if using overlapped I/O on Win95.

    NOTE: One undocumented requirement is that you must have an overlapped socket to use WSAAsyncSelect(), or it will fail with WSAEINVAL (10022)

    NOTE ALSO: Although completion ports will work with sockets on NT4, they will not on Win95 and are not officially Winsock compliant (they are not in the spec).  Since they do provide high performance throughput, however, it's only natural to use completion ports.  One bug I have heard a report of is that a TCP connection reset (abort) on a connected TCP socket was not reported by a completion port.

    WSACloseEvent(): Works fine -- on both Win95 and NT4

    WSACreateEvent(): Works fine -- on both Win95 and NT4

    WSAEnumNetworkEvents(): Works fine -- on both Win95 and NT4

    WSAEventSelect(): Works fine -- on both Win95 and NT4

    WSAGetOverlappedResult(): Works fine -- on both Win95 and NT4

    WSARecv/WSARecvFrom(), WSASend/WSASendTo: Works fine -- on both Win95 and NT4

    WSAResetEvent(): Works fine -- on both Win95 and NT4

    WSASetEvent(): Works fine -- on both Win95 and NT4

    WSAWaitForMultipleEvents(): Works fine -- on both Win95 and NT4

    [Go to top]

    Quality of Service

    Generic QoS using RSVP: Although "GQoS" is not yet implemented in Win95 or NT4 there's a newly completed specification that describes how the generic (protocol-independent) WinSock 2 APIs map to the IETF RSVP protocol.  These will be available in Win98 and NT5, and once implemented the following functions will affect the GQOS settings.

    Once GQOS is fully implemented, the following functions will have their GQOS parameters enabled (where the "G" stands for "Generic" and not for "Group").

    WSAIoctl() 

    The following are some other newly defined APIs that are indirectly related to QoS since they were developed in order to implement support for the Generic QoS scenarios described in the GQoS specification:

    WSAIoctl()

    NOTE: For more information, see the WinSock 2 online documentation at the Microsoft MSDN Library website. 

    As yet, there are no QoS template names defined for the WSAGetQOSByName() function, and there are new APIs for adding persistent new QoS template names. These new APIs, described below, include the mechanism for storage (e.g. the QOSNAME.DLL file for permenant assignments, and the registry for ad hoc assignments).

    NOTE: For more information, see the "Generic Quality of Service (GQOS)" section of WinSock 2 online documentation at the Microsoft MSDN Library website. 

    [Go to top]

    Socket Groups

    Socket Groups have essentially been removed from the WinSock 2 specification. All Socket Group APIs are marked "Reserved for future use" in the specifications.

    What happened was that during the course of refining the behavior of the generic QoS API usage and behavior, it was discovered that the generic QoS APIs were basically redundant of the Socket Groups--both effectively prioritize operations on sockets--but fundementally at odds with them also. Since socket groups were not yet implemented, and Generic QoS APIs were (see Win98), it was decided to remove the socket group APIs.

    WSASocket(): "g" argument is (reserved for future use) - they are ignored - the argument value is ignored (should be zero)

    WSAAccept() condition function: "g" argument is (reserved for future use) - the argument value is ignored (should be zero)

    WSIoctl()

    getsockopt():

    [Go to top]

    MultiPoint and Multicast

    With some qualifications, current Microsoft WinSock 2 implementations (and most WinSock 1.1) support multicast APIs:

    WSAEnumProtocols(): Works fine - Win95 and NT4 both indicate XP1_SUPPORT_MULTIPOINT for UDP sockets, as expected

    WSASocket() WSA_FLAG_MULTIPOINT flags: Flexibly tolerant -- If you don't specify the _C_LEAF and/or _D_LEAF flags, it will still let you use the multipoint APIs. However, if you use invalid flags (call a socket both a leaf and a root, for example), it fails with WSAEINVAL (10022).

    WSAJoinLeaf(): Works fine - on Win95 and NT4 (NOTE: with IP multicast -- AF_INET, SOCK_DGRAM -- it returns the same socket as input)

    WSAIoctl()

    [Go to top]

    Conditional Acceptance

    In general, this is implemented in the current WinSock 2 implementations, but it still doesn't follow the behavior described in the WinSock 2 specification (the implementation doesn't work as the docs say it should).

    WSAAccept(): Works fine - on both Win95 and NT4, however:

    [Go to top]

    Connect and Disconnect Data

    These are largely irrelevant to TCP/IP, although WSASendDisconnect() acts like shutdown (without sending any data).

    WSAConnect(): I haven't tested it (since connect data isn't relevant to TCP/IP, which ignores these buffers)

    WSAAccept(): I haven't tested it (since connect data isn't relevant to TCP/IP, which ignores these buffers)

    WSASendDisconnect(): Works fine -- on both Win95 and NT4 this function call acts like shutdown(how=SD_SEND) since it sends a TCP <FIN> to initiate a graceful close of a TCP connection, although disconnect data buffers are not relevant to TCP/IP (so they are ignored).

    WSARecvDisconnect(): I haven't tested it (since it's not relevant to TCP/IP)

    [Go to top]

    Socket Sharing

    I have tested this within the same process, and it seems to work fine.  Of course, the only problem is that this test is not very helpful since the whole purpose of socket sharing is to allow different processes to reference the same socket. I'll get there eventually...

    WSASocket(): Works fine in my limited testing on both Win95 and NT4

    WSADuplicateSocket(): Works fine in my limited testing on both Win95 and NT4

    NOTE: One interesting result is that although the documentation explicitly says you cannot reuse a protocol info structure in a second call to WSASocket, you can (it doesn't fail). However, it returns the same socket handle as the first call (the legitimate one).

    NOTE ALSO: Although it is possible for threads in a process to share sockets without a problem of any kind, child processes (those created with a call to CreateProcess()) can only share the sockets of the parent process in NT4. In Win95, any reference to a parent process's socket fails with 10038, WSAENOTSOCK. Microsoft has acknowledged this bug, and describes use of DuplicateHandle() in this Knowledge Base Article ID: Q150523

    [Go to top]

    Vendor Extensions

    Well, they're not rejected, but...

    getsockopt() PVD_CONFIG: Wierd -- Succeeds on Win95 and NT4, but returns the value zero in output buffer

    setsockopt() SO_DEBUG: Wierd -- Succeeds, but doesn't provide any debug info I've been able to find yet

    WSAIoctl() SIO_GET_EXTENSION_FUNCTION_POINTER: NotImplemented -- fails with 10022 (WSAEINVAL)

    [Go to top]

    Connected Datagram Behaviors

    Connected datagram behaviors are not pertinent to any WinSock 2 features, but to generic WinSock. As such, they are relevant to some WinSock 2 functions, as well as WinSock 1.1 functions. Whenever I refer to the WinSock 1.1 functions connect(), send()/sendto(), or recv()/recvfrom(), the same also goes true for the WinSock 2 counterparts, WSAConnect(), WSASend()/WSASendto(), and WSARecv()/WSARecvfrom().

    . On Win95 it's possible to use recvfrom()/WSARecvFrom() on a "connected" UDP socket, but on NT4 recvfrom()/WSARecvFrom fail with 10056 (WSAEISCONN)

    NOTE: sendto()/WSASendTo() fail with WSAEISCONN on both (which I don't see any reason for, but anyway...) ---------------------------------------------------------------

    On Win95 connect() to 0.0.0.0 successfully disconnects a socket so both sendto()/WSASendTo() and recvfrom()/WSARecvFrom() work, but on NT4 these don't work (although the socket is disconnected, since no datagrams are sent or received).

    NOTE: it is possible to connect()/WSAConnect() to an valid address and use send()/WSASend() or recv()/WSARecv() at any time, and the outgoing datagrams are indeed sent to the specified destination (which is good :-)
    ----------------------------------------------------------------

    On Win95 after connect() 0.0.0.0 to disconnect a socket, send()/WSASend() fail with 10057 (WSAENOTCONN) as they should, but on NT4 they succeed (although they do not send anything).

    NOTE: on both Win95 and NT4 recv()/WSARecv() block for the timeout period then fail with 10060 WSAETIMEDOUT (although they too should fail with WSAENOTCONN, since they're sure not to receive anything from the 0.0.0.0 address)


    [Go to top]

    Miscellaneous

    Here're some APIs that don't fit under any other category neatly:

    WSAIoctl() SIO_ENABLE_CIRCULAR_QUEUEING: Wierd -- on Win95 fails with WSAEINVAL (10022) , but on NT4 succeeds (haven't tested the actual functionality on NT4 yet)

    WSAIoctl() SIO_FIND_ROUTE: Not implemented for TCP/IP - on both Win95 and NT4 fails with WSAEINVAL (10022)

    WSAIoctl() SIO_FLUSH: Broken -- fails with WSAEINVAL (10022) on both Win95 and NT4

    WSAIoctl() SIO_TRANSLATE_HANDLE: Not implemented (and not ever likely to be) -- fails with WSAEINVAL (10022) in Win95, and WSAENOPROTOOPT (10042) on NT4

    WSAIoctl() SIO_ASSOCIATE_HANDLE: Not implemented (and not ever likely to be) -- fails with WSAEINVAL (10022) on Win95, and WSAENOPROTOOPT (10042) on NT4

    [Go to top]

    Updated 4/18/98 (c) Bob Quinn, 1995-1998

    [Return to Home]