Aric Stewart posted a patch implementing the InternetCheckConnection() API. This function checks whether an Internet connection is available.

Marcus Meissner didn't like the implementation (it was using a ping to a certain address): This can be considered a denail of service attack. Imagine an application doing:
    TryFireUpDialin();
    while (!InternetCheckConnection());
Not good. Also even without a ping getting through we can still access URLs if behind a firewall.

We should probably just check if we have a network connection at all. . Marcus suggested either parsing the output of 'ifconfig' checking for ppp or eth interfaces, or looking at 'route -n' for those interfaces.

Bertho Stultiens proposed to use 'netstat -r -n' to get the correct interfaces.

Stéphane Lussier pointed out that Microsoft's documentation says that when FLAG_ICC_FORCE_CONNECTION flag is set, the function shall try the URL. http://msdn.microsoft.com/workshop/networking/wininet/reference/functions/InternetCheckConnection.asp

Then part of the discussion covered the portability issues: Gerald Pfeifer noted that, for example, the route command had a different location under Solaris or FreeBSD, some different command line switches than the Linux ones, and also some stricter privilege checking (only root can list route tables).

But, after some investigation, 'netstat -r -n' seemed to be portable, and working with user privileges on most unices.

Alexandre Julliard proposed another approach: Having to parse the output of netstat will be more trouble than it's worth IMO. I think we should not try to be too clever here. I'd suggest simply checking for a network interface that is up and not loopback, using the same ioctls than ifconfig does.

Both options seem acceptable, but no implementation has been provided yet.

Jeff Tranter from Corel announced: As part of our WINE development we created a performance profiler tool that supports multi-threaded programs (GNU gprof does not support threads). We've just released it under the GPL and made it available from our open source web site. You can find more information on the tool at http://opensource.corel.com/cprof.html

Instructions for accessing our public CVS server are at http://opensource.corel.com/sourcecode_cvs.html

James Abbatiello gave a try, but run into multiple errors and had to do lots of work by hand, but without any success. It seems that until CVS trees from Corel and WineHQ are properly synchronized, this nice tool shall be hard to tame.