2007/12/18, Daniel Stenberg wrote:

> [...] Please feel free to commit what you deem fit to clean this up.

Done.

> The WSA_poll() issue Mateusz Loskot brings up[*] can
> possibly be "fixed" in libcurl by us simply avoiding to use
> that function no matter what. Or can someone see any
> particularly big impact due to this?
>
> [*] = http://mateusz.loskot.net/2007/12/18/wsapoll-hacks-for-libcurl/

I seriously think that there is nothing to fix.

MSVC (aka VS whatever) and PSDK now WSDK has always depended on the
value of symbol _WIN32_WINNT to indicate which Windows target an
executable library or whatever was being built for.

MS has never guaranteed run time backward compatibility for an
executable. If you build something for W2K using specific features
introduced for W2K, your exe is locked to W2K and later, don't expect
it to run on W98.

So If someone builds libcurl for the latest Windows version, I don't
know why they get surprised it it doesn't run on a previous Windows
version. This is the normal behaviour.

If a library or executable must run on more than one version of
Windows, then it must be built for the lowest version on which it is
supposed to run.

Defining _WIN32_WINNT is not a libcurl issue. We cannot know
beforehand which Windows target the MSVC user desires to build
curl/libcurl for.

Specifying _WIN32_WINNT is not downgrading the library, it is just the
way MSVC uses to indicate the Windows version build target.

Once all that has been said...

Our select() only uses WSA_poll() when a Windows Vista target is being
built (_WIN32_WINNT >= 0x0600) and even further, only uses it if it is
being built to use the WinSock2 API.

In this way if someone is building a Windows Vista target
(_WIN32_WINNT >= 0x0600) they will get the benefits of WSA_poll().

If they wish to be able to run on a previous Windows Version they
should be defining the appropriate _WIN32_WINNT, and in this case
libcurl won't use WSA_poll().

-- 
-=[Yang]=-