|This is the talk page for discussing improvements to the Winsock article.|
|WikiProject Computing||(Rated Start-class)|
- 1 Not very informative...
- 2 Version 1.0 seem missing from the list
- 3 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.
- 4 As one of the authors....
- 5 An IP stack's IP
- 6 There's a difference between "non-blocking" and "asynchronous"
- 7 ODI
- 8 Background
- 9 Porting is dead??
- 10 WSAGetHostByName?
- 11 On versions
- 12 64 bit
- 13 where is the corelation between API DLL confusion and the shortening of the name?!
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 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.
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)
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)
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
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.
- 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. 126.96.36.199 21:51, 22 March 2006 (UTC)
This is a reasonable comment. I'll amplify the comment.
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.
188.8.131.52 21:07, 26 April 2007 (UTC)
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)
Equivalents to the Packet Drivers would be Novell ODI (Open Driver Interface) architecture [...]
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)
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. 184.108.40.206 User:Rosuav (talk) 05:25, 2 January 2008 (UTC)
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.
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