Winsock
From Wikipedia, the free encyclopedia
In computing, Winsock (short for Windows Sockets) is a specification that defines how Windows network software should access network services, especially TCP/IP.
Contents |
[edit] Background
Early Microsoft operating systems, both MS-DOS and Windows, offered limited networking capability, chiefly based on NetBIOS (a technology that Microsoft adopted from IBM). In particular, Microsoft completely ignored the TCP/IP protocol stack. A number of university groups and commercial vendors, including the PC/IP group at MIT, FTP Software, Sun Microsystems, Ungermann-Bass, and Excelan, introduced TCP/IP products for MS-DOS, often as part of a hardware/software bundle. When Microsoft Windows was released, these vendors were joined by others such as Distinct and NetManage in offering TCP/IP for Windows. Even Microsoft offered a limited-function product.
The drawback faced by all of these vendors was that each of them used their own API. Without a single standard programming model, it was difficult to persuade independent software developers to create networking applications, and end users were wary of getting locked in to a single vendor.
There had been a number of successful standardization efforts in the PC networking area over the years. The first of these was a program sponsored by the US Air Force to develop RFC1001/1002, a NetBIOS implementation running over TCP/IP. A second was the Crynwr packet driver effort initiated by FTP Software and led by Russ Nelson.
Winsock was proposed by Martin Hall of JSB Software (later Stardust Technologies) in October 1991. The first edition of the specification was authored by Martin Hall, Mark Towfiq of Microdyne (later Sun Microsystems), Geoff Arnold of Sun Microsystems, and Henry Sanders of Microsoft, with assistance from many others. There was some discussion about how best to address the copyright, intellectual property, and potential anti-trust issues, and consideration was given to working through the IETF or establishing a non-profit foundation. In the end, it was decided that the specification would simply be copyrighted by the four authors as (unaffiliated) individuals.
[edit] Technology
The Winsock specification defines two interfaces: the API used by application developers, and the SPI, which provides a means for network software developers to add new protocol modules to the system. Each interface represents a contract. The API guarantees that a conforming application will function correctly with a conformant protocol implementation from any network software vendor. The SPI contract guarantees that a conforming protocol module may be added to Windows and will thereby be usable by an API-conformant application. Although these contracts were important when Winsock was first released, they are now of only academic interest. Microsoft has shipped a high-quality TCP/IP stack with all recent versions of Windows, and there are no significant independent alternatives. Nor has there been significant interest in implementing protocols other than TCP/IP.
Winsock is based on BSD sockets, but provides additional functionality to allow the API to comply with the standard Windows programming model. The Winsock API covered almost all the features of the BSD sockets API, but there were some unavoidable obstacles which mostly arose out of fundamental differences between Windows and Unix (though to be fair Winsock differed less from BSD sockets than the latter did from STREAMS).
However it was a design goal of Winsock that it should be relatively easy for developers to port socket-based applications from Unix to Windows. It was not considered sufficient to create an API which was only useful for newly-written Windows programs. For this reason, Winsock included a number of elements which were designed to facilitate porting. For example, Unix applications were able to use the same errno variable to record both networking errors and errors detected within standard C library functions. Since this was not possible in Windows, Winsock introduced a dedicated function, WSAGetLastError(), to retrieve error information. Such mechanisms were helpful, but application porting remained extremely complex. Many "traditional" TCP/IP applications had been implemented by using system features specific to Unix, such as pseudo terminals and the fork system call, and reproducing such functionality in Windows was problematic. Within a relatively short time, porting gave way to the development of dedicated Windows applications.
[edit] Specifications
- Version 1.0 (June 1992) defined the basic operation of Winsock. It was kept very close to the existing interface of Berkeley sockets to simplify porting of existing applications. A few Windows-specific extensions were added, mainly for asynchronous operations with message-based notifications.
- Although the document didn't limit support to TCP/IP, TCP and UDP were the only protocols explicitly mentioned. Most vendors only delivered TCP/IP support, although Winsock from DEC included DECNet support as well.
- Version 1.1 (January 1993) made many minor corrections and clarifications of the specification. The most significant change was the inclusion of the gethostname() function.
- Winsock 2 was a backwards-compatible extension of Winsock 1.1. It added support for protocol-independent name resolution, asynchronous operations with event-based notifications and completion routines, layered protocol implementations, multicasting, and quality of service. It also formalized support for multiple protocols, including IPX/SPX and DECNet. The new specification allowed sockets to be optionally shared between processes, incoming connection requests to be conditionally accepted, and certain operations to be performed on socket groups rather than individual sockets. Although the new specification differed substantially from Winsock 1, it provided source- and binary-level compatibility with the Winsock 1.1 API.
- Versions 2.0.x (May 1994 onwards) had internal draft status, and were not announced as public standards.
- Version 2.1.0 (January 1996) was the first public release of the Winsock 2 specification.
- Version 2.2.0 (May 1996) included many minor corrections, clarifications, and usage recommendations. It was also the first version to remove support for 16-bit Windows applications.
- Version 2.2.1 (May 1997) and Version 2.2.2 (August 1997) introduced minor functionality enhancements. Mechanisms were added for querying and receiving notification of changes in network and system configuration.
- The IPv6 Technical Preview for Windows 2000 (December 2000) saw the first implementation of RFC 2553 (March 1999, later obsoleted by RFC 3493), a protocol-independent API for name resolution, which would become part of Winsock in Windows XP.
[edit] Implementations
[edit] Microsoft implementations
- Microsoft did not supply an implementation of Winsock 1.0.
- Version 1.1 of Winsock was supplied in an add-on package (called Wolverine) for Windows for Workgroups. It was an integral component of Windows 95 and Windows NT 3.x.
- Version 2 of Winsock was supplied in an add-on package for Windows 95. It was an integral component of Windows 98, Windows NT 4.0, and all subsequent Windows releases. (Microsoft did not supply implementations of Winsock 2 for Windows 3.x or Windows NT 3.x.)
- Recent versions of Winsock 2.x have been delivered with new Windows releases or as part of service packs.
[edit] Other implementations
- Among the other vendors offering Winsock-compliant TCP/IP stacks were (alphabetically) 3Com, Beame & Whiteside, DEC, Distinct, FTP Software, Frontier, IBM, Novell, Microdyne, NetManage, Sun Microsystems and Trumpet Software International
- Trumpet Winsock was one of the few Winsock 1.0 implementations that could be installed under Windows 3.0, which had no built-in support for Winsock. Trumpet was also the most popular shareware implementation of Winsock for Windows 3.x.
[edit] Source
Originally adapted from: Aboba, Bernard D., comp.protocols.tcp-ip.ibmpc, Frequently Asked Questions, 1993. Usenet: news:news.answers. Thanks to http://www.foldoc.org.
[edit] See also
[edit] External links
- Windows Sockets - Open Source Implementation of a client & server windows sockets
- Sockets FAQ - Windows Sockets FAQ
[edit] Microsoft
- The Windows Sockets API
- Porting Berkley Socket programs to Winsock
- Windows Network Development blog — Microsoft developer blog covering Winsock, WSK, WinINet, Http.sys, WinHttp, QoS and System.Net, with a focus on features being introduced in Windows Vista