There is a lot here that is suboptimal.

One might use %COMSPEC% to deal with the issue of which command shell to run... if you want to trust an environment variable, always a bad idea. For example some "alternate shell" packages rewrite COMSPEC's value to a command shell that uses different command line syntax.

Using Shell() to run an external process for something like this seems pretty wasteful. Using it to run a command shell to run the external program just to get redirection (to disk!)... well firing off two external processes is even worse, and programs are not supposed to rely on a command shell being available anyway. At least use anonymous pipes and run just the one program!

Then you have the ICMP ping issue which has been beaten to death.


What I don't understand is that if detecting that the server can't be reached is the goal why not just connect and see?

If you can't wait for the Winsock connection timeout interval and retries, then why not just use a Timer set to the longest interval you want to wait (3, 5, 10 seconds)? If the connection is accepted before the Timer goes off, disable the Timer and continue. If the Timer fires then disable it, close the connection attempt, and signal an error. If a connection error such as a sckConnectionRefused comes back... etc.

A small amount of code that bypasses all of the shaky practices outlined above.


I have tested this OK with Win2000 and WinXP. My colleague has reported that it also works fine with Vista. As yet not tested with Win7.

In case anyone else finds this thread via the search routine, as did I, I hope that this OS version information may prove of assistance.
There isn't an OS version issue here, it's an OS type issue. NT based Windows uses cmd.com as its default command shell, that's all. Almost nobody is using Win9x seriously anymore anyway.