In computing, the Windows Sockets API, which was later shortened to Winsock, is a technical specification that defines how Windows network software should access network services, especially TCP/IP. It defines a standard interface between a Windows TCP/IP client application (such as an [client] or a  client) and the underlying TCP/IP protocol stack. The nomenclature is based on the Berkeley sockets API model used in Berkeley UNIX for communications between programs. Initially, all the participating developers resisted the shortening of the name to Winsock for a long time, since there was much confusion among users between the API and the DLL library file (winsock.dll) which only exposed the common WSA interfaces to applications above it. Users would commonly believe that only making sure the DLL file was present on a system would provide full TCP/IP protocol support.
In particular, Microsoft completely ignored the TCP/IP protocol stack at that time. 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 2.0 was released, these vendors were joined by others such as Distinct and NetManage in offering TCP/IP for Windows. The drawback faced by all of these vendors was that each of them used their own API (Application Programming Interface).
Without a single standard programming model, it was difficult to persuade independent software developers to create networking applications which would work with any vendor’s underlying TCP/IP implementation. Add to this the fact that end users were wary of getting locked in to a single vendor and it becomes clear that some "standardisation" work was needed.
In November of 1990 Lynn "Jess" Jessop then the Director of Engineering for ICL North America met with Rob Barrow, the B in JSB, and Steve Jones, the J in JSB, at his Reston Virginia ICL office. At the time Jess's main product Officepower ran over TCP/IP and on Windows 2.0 using Visionware’s desktop. But that required supporting seven different flavors of TCI/IP and updating TSR programs each time one of the vendor came out with a new version of their stack.
Rob wanted Jess to adopt JSB's desktop as the underlying technology instead of Visonware. Jess told Rob what he wanted was a Berkeley Socket like interface on the Windows desktop, not another desktop on a desktop as it currently was.
ICL being the open standards leader in the world, Jess wanted it to be an open standard. That he told Rob he would buy. Rob agreed and took the idea back to England. Jess visited Rob at JSB Headquarters in England in December and was introduced to Martin Hall.
Martin invited Jess to his home for dinner, a long night of discussion over many bottles of wine and Martin was up to speed. Jess, Rob and Martin continued to work on the initial design and started expanded the group.
Although ICL's and Jess Jessop's part is often left out of the official histories Jess represented ICL as a founding member of the original Winsock committee, edited the first three drafts and attended the initial sessions. When it was clear the project was well underway and transferred to JSB's offices in Scott's Valley California Jess left ICL and withdrew from the committee.
The Windows Sockets API was proposed by Martin Hall of JSB Software (later Stardust Technologies) as a BoF (Birds of a Feather) discussion on the CompuServe BBS network 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 and J Allard 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 five authors as (unaffiliated) individuals. (J Allard was later granted a large corner office at the Microsoft "campus" in which he kept two live Iguanas, STOCK and OPTION, as they were aptly named).
Windows Sockets is based on BSD sockets, but provides additional functionality to allow the API to comply with the standard Windows programming model. The Windows Sockets 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 Windows Sockets differed less from BSD sockets than the latter did from STREAMS). All function calls in the API begin with the moniker WSA, e.g. WSAGetHostByName() for making a hostname lookup. It should also be noted that Windows Sockets expanded on BSD Sockets functionality, by offering "non-blocking" or asynchronous Sockets (accessed by adding WSAAsync before the desired function; e.g., WSAAsyncGetHostByName())
However it was a design goal of Windows Sockets 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, Windows Sockets 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, Windows Sockets 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.