Hi Chris!
Ok, you asked for it so I am going to get technical on you!
The Winstep Update Manager contacts the Winstep.net server via port 80 using the HTTP protocol. It downloads a simple text file (just like your browser would if you typed
http://www.winstep.net/<xxxx>.txt in the address bar) that holds information about the latest versions, which is then used to compare with the versions installed on your computer... as simple as that.
The 'apparent' (I'll explain why I say apparent below) large CPU utilization problem might be caused by one of two things: a DNS (Domain Name Server) resolution issue or a 3rd party DLL injected into the Winstep process (this is what AV software usually does).
When Winstep applications communicate via the web, Winsock gets passed a domain name - e.g.;
http://www.winstep.net - which must first be resolved into an IP address via WSAAsyncGetHostByName. Unlike the actual 'get the data' phase that comes next, and which is performed asynchronously, the DNS lookup actually loops the code with a DoEvents instruction in the middle until the domain name has been resolved into an IP address.
Now, what does DoEvents do? DoEvents passes control to the operating system. Control is returned after the operating system has finished processing the events in its queue.
The loop waits for a specific condition (in this case either a timeout or an IP address), and, if that condition has not been met yet, it uses DoEvents to suspends the current thread and pass execution back to the Windows message pump. In order words, with DoEvents the application 'surrenders' its processing time to Windows so that other parts of the application continue to be responsive (without DoEvents, the application would simply 'block' until the condition was met and the loop exited, with DoEvents it remains responsive to mouse events, etc...). The Windows message pump processes any pending events and then returns execution to the instruction after 'DoEvents'.
If the message queue is empty or nearly empty (as it will be most of the time because all this happens very rapidly), the tighter (and faster) the DoEvents loop will be. The spike in CPU activity you see is NOT because the application is busy doing something processor intensive, but because the Windows message pump is being executed more times than normal. In other words, it's not the application itself using all that CPU, but the Windows message pump. However, because the purpose of the Windows message pump is to execute events for *all* running applications, you are not taking processing power away from the rest of the system - you are doing the exact opposite, in fact.
This would be pretty evident when using DoEvents in a single core processor: in that case the application using DoEvents would appear to be using 100% of the CPU, but run another processor intensive application at the same time and you will see that it runs at full speed instead of really slow as it would happen if the DoEvents application was *actually* doing something processor intensive.
So, getting back to our DNS resolution routine, if there is a problem converting that domain name into an IP address, then the loop will run until a timeout condition occurs (usually 30 seconds). If DNS resolution fails for some external reason (DNS server is down, or *something* in your system is preventing it?) then the application is unable to get the corresponding IP address and, without it, communication cannot proceed.
I suspect this is what is happening to you, although I have no idea why.
So why use DoEvents resolving domain names when the remain data exchange is truly asynchronous (i.e.; packets are sent to the application as they are received instead of the application polling for them)? Because the original Winsock library used by Winstep did *everything* in a synchronous way and was modified so that the important (and much more time consuming) 'get the data' part was done asynchronously. I suppose I could have modified the DNS resolution part so it too was truly asynchronous, but it would be a lot of work for very little return since domain names are *usually* resolved in milliseconds.
As for 3rd party DLLs injected into your process, the reason why they might make your application run 'slow' or use a lot of CPU is because, even though the DLL does not belong to your application, it is running in the same process space. Anything that DLL does will be attributed to YOUR process, NOT to the process that injected that DLL in the first place.
For instance, if an AV injects a DLL into your process that scans a file every time your application opens one, the time spent by that DLL scanning the file will appear under your process name in Task Manager (i.e.; that time will be added to the 'normal' processing time used by your application to perform its own tasks). Hardly fair but this is how it works.
P.S. I run Eset Smart Security here (so NOD32 is my AV too) and I have no problems with it whatsoever.
Posted: Mon Aug 08, 2011 11:44 pm 
