Service Controller

Since releasing a version of Weather Message that runs as a service, several customers have asked what happened to the user interface. Well when an application runs as a service, most of the time you lose the user interface because the application is running in the background. Most software packages provide another application that can be used to monitor the background service.

I have spent the last week studying interprocess communications. I have decided to use named pipes since they appear to be quite efficient. Named pipes are basically memory files that can be shared across process boundaries. I need a way for a 'controller' application to talk to the server and get the screen updates. Named pipes should do this well.

The 2.0 framework does not have built-in support for named pipes, so it was necessary to write all of the code to communciate with named pipes. Support for named pipes will be in the Microsoft 3.5 Framework. That Framework however will not work on Windows 2000 computers. The 3.0 Framework does support a mechanism that I could have used, it also does not support Windows 2000.

I completed the routines today and the tests look good. I should be able to create the WxController application sometime this week. It will be a small application. The big change will be updating Weather Message Server so that it will send data to the connected controller application.

One good point is that named pipes can be used across a network. So it will be possible to run WxController on a remote computer to monitor the server. I will say that this is only recommended on fast networks. If the primary goal was to monitor remotely, then using tcp/ip sockets would be a better approach.