WPUModifyIFSHandle

The WPUModityIFSHandle function receives (possibly) modified IFS handle from WS2_32.DLL.

SOCKET WPUModifyIFSHandle (
  DWORD dwCatalogEntryId,   
  SOCKET ProposedHandle,   
  LPINT lpErrno            
);

Parameters

dwCatalogEntryId: [in] A descriptor identifying the calling service provider.
ProposedHandle: [in] An Installable File System(IFS) handle allocated by the provider.
lpErrno: [out] A pointer to the error code.

Remarks

The WPUModityIFSHandle handle allows the WS2_32.DLL to streamline its internal operations by returning a possibly modified version of the supplied IFS handle. It is guaranteed that the returned handle is indistinguishable from the proposed handle as far as the operating system is concerned. IFS providers must call this function before returning any newly created socket descriptor to a service provider. The service provider will only use the modified handle for any subsequent socket operations.

This routine is only used by IFS providers whose socket descriptors are real Installable File System handles.

Layered Service Provider Considerations

This procedure may also be used by a layered provider that is layered on top of a base IFS provider and wants to expose the base provider's socket handles as its own instead of creating them with the WPUCreateSocketHandle call. A layered provider that wishes to "pass through" the IFS socket handles it receives from the next layer in the chain can call WPUModifyIFSHandle, passing its own catalog entry Id as dwCatalogEntryId. This informs the Windows Sockets DLL that this layer, and not the next layer, should be the target for SPI calls involving that socket handle.

There are several limitations a layered provider should observe if it takes this approach.

The provider should expose base provider entry points for WSPSend and WSPRecv in the procedure dispatch table it returns at the time of WSPStartup to make sure the Windows Sockets SPI client's access to these functions is as efficient as possible.
The provider can not rely on its WSPSend and WSPRecv functions being invoked for all IO, particularly in the case of the IO system functions ReadFile and WriteFile. These functions would bypass the layered provider and invoke the base IFS provider's implementation directly even if the layered provider puts its own entry points for these functions into the procedure dispatch table.
The provider can not rely on any ability to post-process overlapped IO using WSPSend, WSPSendTo, WSPRecv, WSPRecvFrom, or WSPIoctl. Post-processing notification may happen through completion ports and bypass the layered provider entirely. A layered provider has no way to determine that a completion port was used or determine what port it is. The layered provider has no way to insert itself into the notification sequence.
The provider should pass through all overlapped IO requests directly to the base provider using the original overlapped parameters (for example, WSAOVERLAPPED structure and completion routine pointer). The provider should expose the base provider entry point for WSPGetOverlappedResult. Since some overlapped IO requests can bypass the layered provider completely the layered provider cannot reliably mark WSAOVERLAPPED structures to determine which ones it can report results for, and which ones would have to be passed through to the underlying provider's WSPGetOverlappedResult. This effectively means that WSPIoctl has to be a pass-through operation to the underlying provider.

Return Values

If no error occurs, WPUModifyIFSHandle returns the modified socket handle. Otherwise, it returns INVALID_SOCKET, and a specific error code is available in lpErrno.

Error Codes

WSAEINVAL

The proposed handle is invalid.

QuickInfo

  Windows NT: Yes
  Windows: Yes
  Windows CE: Unsupported.
  Header: Declared in ws2spi.h.