That brings up an interesting question, whether or not the Weatherlink software itself is using the DLL to communicate to the logger. If it is, and the DLL is properly writen, then multiple applications could access the logger at the same time.
My guess is that it would be too convenient and obvious, so this is probably not the case. 
No, they don't use the DLL itself in their code. Even if they did, the DLL is just a communications wrapper, again accessible by a single program at a time. My real hope is that they will someday create an NT service with a COM interface that will provide access to the data in a shared fashion, firing events as data arrives, doing the logging, that sort of thing. Then, you could run their WeatherLink as a front end when you want to see the data, or you could write your own code to display it; maybe a little weatherbug-like tool tray application, trigger alarms, operate water sprinklers, or whatever.
The serial nature of the communications protocol pretty much prevents two programs from cooperatively sharing the port -- how would one program know if the data is what it requested? Worse, what would happen if both programs sent conflicting requests to the VP? One might be asking for a dump of the archive, while the other requests the real time data, or both could ask for dumps, etc. But if the data were available on a COM interface, it could be constantly requesting and receiving everything, and providing it to all consumers in a thread-safe fashion. And as a service, it also would run constantly in the background, not requiring me to stay logged in just to keep my web site up-to-date.
VirtualVP is one way to sort-of accomplish the goal. It allows one program to act as the "host", doing the data requests, downloading and logging the data, etc. So you could run Weatherlink as this "main host", but open another serial port to read the data in a different app (like VWS or meteo.) I'm not sure if VirtualVP does any "lockout" to prevent collisions.
