Talk:Winsock

This is the talk page for discussing improvements to the Winsock article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

I'll fix the winsock page this weekend, it is out of date and definately needs updating on Win 2000 and Win XP implemenations of the protocol. --Jared Buck 22:33, 3 Dec 2004 (UTC)

Not very informative...

My apollogies in advantance to the person who wrote this article, but this article doesn't quite explain the real funtion of Winsock.

I think the shiva ppp dialer should get an (dis)honourable mention. —Preceding unsigned comment added by 93.133.82.83 (talk) 17:59, 10 August 2009 (UTC)[reply]

i agree it is not very informative to a person who does not know what it is. Good back ground. to a person who has is searching for a definition and an understanding of it I am no clearer than it some software for networking.

andrew —Preceding unsigned comment added by 220.233.43.212 (talk) 00:58, 6 October 2009 (UTC)[reply]

Version 1.0 seem missing from the list

Maybe it's just nitpicking, but if there's a list of versions, it has to be complete... --tyomitch 01:21, 2 September 2005 (UTC)[reply]

This isn't meant to be an exhaustive list, there were quite a few versions of Winsock from quite a few different vendors. This is just a list of which versions were bundled with Windows. AlistairMcMillan 01:53, 2 September 2005 (UTC)[reply]

Version 1.0 was bundled with Windows 3.x, as one can infer from the words 'has been supported ... since Windows 3.0', but shouldn't that be stated explicitly? --tyomitch 02:58, 2 September 2005 (UTC)[reply]

Bzzt wrong. Winsock for Windows 3.x was a separate download. See Windows 3.x AlistairMcMillan 03:26, 2 September 2005 (UTC)[reply]

Just found out: Winsock couldn't be supported by Windows 3.0 in any case, because Windows 3.0 was released two years before the initial Winsock spec. --tyomitch 21:22, 5 September 2005 (UTC)[reply]

Another mismatch: David Treadwell of Microsoft joined the team for version 1.1 of the specification, published in January 1993. - David Treadwell is listed in the Credits section of Winsock v1.0 spec, dated June, 1992; am I to delete his mention? --tyomitch 22:34, 5 September 2005 (UTC)[reply]

Windows Sockets has been supported by every version of Microsoft's operating system since Windows 3.1, yet the first version of Windows to be shipped with Winsock was Windows 95.

Regarding this snippet from the article: I think it's poorly worded. "yet the first..." makes it sound like Microsoft sat on its hands with respect to incorporating winsock into Windows, when indeed it was incorporated into the first major version of Windows to be released after Winsock 1.0

As one of the authors....

Microsoft's involvement during the early stages of the WinSock work was ambiguous, to say the least. The individual participants from Microsoft were active and engaged, but Microsoft's corporate commitment was very unclear. It's important to remember that at the time of Winsock 1.0, Microsoft had a lousy reputation in the TCP/IP area: their first home-grown stack was sadly deficient in features and performance.

While I'm commenting, I'm confused as to why Tyomitch hacked the author affiliations to remove all links except for Microsoft. Either all author affiliations should be included, or none. I'm going to restore them.

If you want to know what really happened in WinSock, feel free to ask me.

Geoff Arnold, co-author of WinSock 1.0 and 1.1.

Recall someone(?) did a port of the BSD TCP/IP stack sources (compiled with much work as 16-bit?) to run on Windows. The port was a bit rough, but arguably better than the then-present alternatives. The guy disappeared, and several months later Microsoft had a decent (dramatically better) BSD-compatible TCP/IP stack. I had always suspected the guy took his port to Microsoft. pbannister (talk) 20:51, 16 March 2020 (UTC)[reply]

An IP stack's IP

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 individual authors. (It seems unlikely that corporate legal departments would sanction such an approach these days.)

This comment hides a great big deal. It's an encyclopedia's duty to inform, so no need to be stingy with explanation here. Why would this approach not be sanctioned "these days"? This comment should either go or it should be expanded. It's obvious intellectual property issues in software are not now what they were 15 years ago, but that's hardly a full explanation. 82.92.119.11 21:51, 22 March 2006 (UTC)[reply]

This is a reasonable comment. I'll amplify the comment.

Geoff Arnold

There's a difference between "non-blocking" and "asynchronous"

Under the "Technology" section, the article states that "It should also be noted that Windows Sockets expanded on BSD Sockets functionality, by offering "non-blocking" or asynchronous Sockets (accessed by calling WSAAsynch before the desired function, e.g. WSAAsynchGetHostByName())"

The implication is that "non-blocking" and "asynchronous" are the same, and that's not correct. "Non-blocking" simply means that a call to a socket function will return immediately without blocking further execution of the program. "Asynchronous" refers to a notification method whereby Winsock will notify a program when a socket function has completed.

Moreover, the BSD sockets already had "non-blocking" sockets, so it's factually incorrect to state that Winsock "expanded" on BSD in this resepct.

Finally, the "Async" part is spelled incorrectly (i.e., the name of the function in the example is "WSAAsyncGetHostByName()" not "WSAAsynchGetHostByName()"), and not all winsock functions have asynchronous counterparts.

63.207.173.11 21:07, 26 April 2007 (UTC)[reply]

Totally agree with the comment above, moreover the sentence citing "WSAAsynchGetHostByName()" seems to suggest that the sole way to do asynch I/O is thru functions that have WSAAsync prefixed to them, as many of us know many other functions e.g. WSASend, WSARecv do asynchronous I/O too .. Ranjit.puri (talk) 06:40, 17 June 2008 (UTC)[reply]

ODI

Equivalents to the Packet Drivers would be Novell ODI (Open Driver Interface) architecture [...]

Is it Open Driver Interface or Open Data-Link Interface? --Abdull 19:45, 8 May 2007 (UTC)[reply]

Background

The background section is really interesting and informative. The only thing missing are a few dates here and there. --Abdull 17:45, 9 May 2007 (UTC)[reply]

Porting is dead??

"Within a relatively short time, porting gave way to the development of dedicated Windows applications."

Sorry. This is not right... or if it is, then development of dedicated Windows apps is itself giving way to porting - or, to use more buzzwordy terminology, cross-platform coding. Now, it's true that some things are hard to port - graphical interfaces are notorious for this. But it is possible to write an ANSI C or C++ program which can be compiled for any POSIX-compliant Unix (including Linux in many/all of its variants), for OS/2, for anything under the Sun (and for Solaris too). And it's possible for that program to use socket services. Then you come to try to put it on Windows. Suddenly you need a whole lot of #ifdef statements, governing for instance a dedicated WSAStartup call, some changed API names, the different data type (SOCKET instead of simply int), new ways to code the same error checks, and the occasional difference in format.

I'm sorry if this sounds like a rant, because it's not meant to be. All I'm saying is that the Microsoft alterations to the BSD standard socket terminology are not as benign as this article implies. 210.84.46.48 User:Rosuav (talk) 05:25, 2 January 2008 (UTC)[reply]

WSAGetHostByName?

Does such a function exist? There does appear to be a function called "gethostbyname" without the WSA prefix. Nitwit005 (talk) 16:30, 9 May 2008 (UTC)[reply]

On versions

The biggest problem, in my opinion, with Winsock as used by Microsoft, is versions...

The specification version is supposed to become an API constant, using a mapping that only allows for two numbers. Thus, 2.2.1 referenced in the article doesn't map to an API version number.
Microsoft appears to have renumbered the versions. Windows NT 4.0 SP3 included version 2.1. Windows NT 4.0 SP6 included version 2.2. I have seen a version 2.3 (but can't tell you what version of windows it was). I have seen all 3 of these in Microsoft documentation. Microsoft now describes the current version as 2.2.
Microsoft doesn't support old version. This means if you acquire the 2.0 specifications, and properly write a program to use it, it can't run on current Windows implementations! To make your winsock program run you must initialize winsock with a fixed version, find out what version the Microsoft implementation claims to support, and initialize that version. As such, you are claiming that your program is compatible with a version of the API that was not necessarily conceived of when you wrote your program. This defeats the purpose of API versioning.

--David Garfield (talk) 01:10, 10 June 2008 (UTC)[reply]

64 bit

Is winsock2 part of windows vista? vista 64? If so... where are the libraries? what are they named? --75.146.141.206 (talk) 00:36, 11 February 2009 (UTC)[reply]

where is the corelation between API DLL confusion and the shortening of the name?!

and more importantly, how do you focus on this drone shit? really, I need to learn that.

please send all drugs to 123 magic st, fairyville, yours truly the swanky moonriver

Support for version 2.0

This page: https://msdn.microsoft.com/en-us/library/windows/desktop/ms742213%28v=vs.85%29.aspx documents that there is support for version 2.0

Windows Sockets code and design are based on BSD sockets[...]

Stating that code is based on BSD sockets without providing any citation seems wrong. While there are a lot of discussions about that topic out there, most of them interchange things like the sockets API and its implementation with tools like nslookup and their code etc., which doesn't have anything to do with Winsock itself. Additionally, one can find good quality sources that implementation is not based on BSD code:

 No, it's not true.  For a while we thought it was, but we proved to be
 incorrect.  Microsoft's network stack was written by a Scottish
 company called Spider.

http://www.silug.org/lists/silug-discuss/200403/msg00165.html 178.0.5.149 (talk) 08:05, 14 July 2018 (UTC)[reply]

BoF conference - reference

"Windows[tm] Sockets Network Programming" by Bob Quinn and Dave Shute, Addison-Wesley Advanced Windows Series, 1996 isbn 0-201-63372-8

Forward by Martin Hall, WinSock Group Chairman, CTO Stardust Technologies, Inc.

"In the Fall of 1991, Martin Hall, of Stardust Technologies, organized an informal "birds-of-a-feather" gathering at InterOp, the flagship trade show of the TCP/IP networking industry. The purpose of the meeting was to investigate the possibility of creating a standard API for TCP/IP applications in Microsoft Windows. Representatives from PC-based TCP/IP protocol stack vendors and Windows network application developers were in attendance. ... became a formal working group. ... ... design an API ... Berkeley Sockets as starting point ... Version 1.0, released in June of 1992.."

Many additional references in the back for magazine articles, etc. (I have no idea how to best work this into the article, as a bystandander.) — Preceding unsigned comment added by Thinkadoodle (talk • contribs) 13:32, 29 April 2019 (UTC)[reply]