Can anyone tell me the actual difference between winsock.h and winsock2.h, they both use the same lib, no?
And why I can't inlcude winsock2.h in my VS 2003 projects?
thank you.
Printable View
Can anyone tell me the actual difference between winsock.h and winsock2.h, they both use the same lib, no?
And why I can't inlcude winsock2.h in my VS 2003 projects?
thank you.
winsock.h should be used with wsock32.lib and winsock2.h should be used with ws2_32.lib
For most windows applications, you wont notice a difference. Winsock2 introduces some new functions for new networking protocols (like bluetooth). It also introduces something called LSP which layers all winsock functions on top of the base networking functions. The cool thing about this is that you can create your own layers which will in turn get called by the winsock implementation when any application calls the function you layered. Think of it as an easy way to hook any winsock function.
Winsock2 is completely backwards compatible with the original winsock, so the only reason you would ever want to use the original winsock is when you are targeting a platform that doesn't support winsock2 (Everything that is newer than Windows 3.11 supports winsock2 I believe).
Does the winsock2.h also includes the implemintation of IPv6 functions?
IPv6? I don't think that windows yet has a working implementation of IPv6. It doesn't matter, I don't think the world will ever switch to using it.
I believe as of SP1 Windows XP includes IPv6, and Windows 2003 includes it as well.
As for the off-topic part of switching to it, its already started. I believe mostly in the eastern Asian countries, due to the fact they got only small chucks of the IPv4 address space, and were already using nearly all of it, so they are already starting the move. As for the USA, that's a different story.
Is there a reason why I can't include <windows.h> before <winsock2.h>, it gives me tons of errors, but once I switch their order everything is okay... why is that?
Your header is probably screwed up.
As for 'switching to IPv6,' it'll definately happen. IPv4 is drastically running out of space. IPv4 is shown as a set of four decimal numbers from 0 to 255 delimited by decimals (a range of 256 numbers), therefore, by doing a simple power calculation, you can determine there can be approximately 4,294,967,296 IPv4 addresses. That doesn't take into account ANY of the reserved ranges (including 127.*.*.* which all just point to 'localhost,') IPv6 expands on space, bringing in A LOT more room for people, (as some of me and my friends have speculated) IPv6 will simply 'overlap' IPv4 and once that conversion is complete, IPv4 will probably just be dismantled. On that note, yes, the Winsock2 library DOES have some IPv6 functionalities such as setsockopt options and such.
Winsock2 also incorperates the use of Raw Sockets which makes it pretty simple to do things like network scanners or basic firewalls by using a WSAIoctl call with SO_RCVALL (or some variation thereof) so you get passed ALL the pakcets like in a transparent layer.
His header isn't screwed up (at least not any more screwed up than everyone elses header). windows.h stupidly includes winsock.h by default, so if you try to include winsock2.h afterwards, you get double declarations of all the winsock structures and typedefs.Quote:
Your header is probably screwed up.
One way to get around this is to define WIN32_LEAN_AND_MEAN before you include windows.h. This causes windows.h not to include a lot of header files which aren't used much (one of these is winsock.h). Another way to get around this is to define _WINSOCKAPI_ before including windows.h. This will cause winsock.h to not be included. The last way to get around this (as you've already found out) is to include winsock2.h first. This defines _WINSOCKAPI_ so that winsock.h wont be included. In fact, if you include winsock2.h, you don't even need to include windows.h at all since winsock2.h does this for you.
Except this functionality is broken (intentionally) on windows 2000 and newer versions of windows.Quote:
Winsock2 also incorperates the use of Raw Sockets which makes it pretty simple to do things like network scanners or basic firewalls by using a WSAIoctl call with SO_RCVALL (or some variation thereof) so you get passed ALL the pakcets like in a transparent layer.
Raw sockets or the SIO_RCVALL call? I can assure you that Raw sockets will work almost exactly (ignoring little idiosyncrasies such as startup) as the linux implementation will work in almost everything but Windows XP SP2 (there's even a wsock2 library upgrade for windows 95), as for the SIO_RCVALL functionality, I can also assure you that this functionality in fact works, the only requirement is that you bind to an explicit local interface (meaning absolutely no using bind(); on INADDR_ANY) and you have to be of administration privledges. But you know, windows dependencies and all.
Oops, you're right. It is only XP SP2 (and presumably newer) versions that have broken raw socket support. You can no longer do TCP sends over RAW sockets.