My office recently moved to a new building and we had a security system installed. It turns out that the software interface to this system is called WinDSX, and it is one of the worst pieces of software I've ever seen.

The most notable way I came to this conclusion is that I wanted to move the "Communications Server" application, which was running on a standalone computer, to be a service on an existing server. All this program does is collect data from the security system itself and allow the client program access to this data. In fact, by default, this program does not have any user interface. You can run it with a "-visible" flag and it will show a basic window that simply shows a text log of system activity (badges read, etc.) and nothing else besides a File->Exit menu item. So it seemed like it should be trivial to get it to run as a service with instsrv and srvany. Except it's not.

It turns out that they specifically designed the application so that it could not be run as a service. At least that's what they tell me. My guess is that they in fact have no idea what they're doing, so they turned their bug that they didn't know how to fix into a feature. Of course, since this means that you have to log in to run this server application, it makes the computer running it virtually unusable for anything else. (One of the people I spoke to said something along the lines of "how can you be using a computer if you're not logged into it?".)

Then another excuse they gave me is that I wouldn't want to run it as a service concurrently on another computer anyway because "the program will consume about 80% of the available CPU cycles regardless of the speed of the PC." I will point out that while my observed CPU consumption was only about 50%, the security system is only controlling about four doors and a dozen sensors. And the security system is independent of this server. It's its own dedicated system; the software is used solely for monitoring and configuration, and there was no activity on the system. And just to make sure, I looked at the network utilization (all of the communication between the software and the security system is over the network) and it was pretty consistent at just under 4kBps, a large portion of which is bound to be normal Windows chattiness.

They also told me that it was a security concern. Apparently it's more secure for me to have to log into the computer and let it run logged in all the time than for it to run as a service. And, if I want to make sure that it starts on boot, I have to get Windows to autologin, which is so secure. They should really tell all the other software designers out there about their new security findings. It will change the face of network services forever.

And you say, well, at least you can segregate the computer from the Windows Domain. That will help with security a little. As it turns out, no. Because in addition to the network service, I also have to use Windows Networking to share the database files to the computers that will be accessing the service. Which would imply to me that the service isn't even servicing the clients more than coordinating concurrency as they write directly to the shared database files.

The biggest problem, though, is that they claim that these things are designed this way. They intended to soak the CPU. They intended to prevent me from running it as a service at all costs. Hell, the client application has no Windows buttons, no minimize, no maximize, not even close.

So, the moral of this story is: if you are ever party to selecting a security system, ask the vendor what software they use. If it's WinDSX, run. Run and don't stop.