Talk:Winsock

From Wikipedia, the free encyclopedia

 This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
??? This article has not yet received a rating on the quality scale.
??? This article has not yet received an rating on the importance scale.

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)

Contents

[edit] 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.

[edit] 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)

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)
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)
Bzzt wrong. Winsock for Windows 3.x was a separate download. See Windows 3.x AlistairMcMillan 03:26, 2 September 2005 (UTC)

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)

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)

[edit] 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

[edit] 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.

[edit] 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)

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

Geoff Arnold

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] On versions

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

  1. 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.
  2. 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.
  3. 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)