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.

Have you tried putting an amperstand after the executable name and adding it to your rc.local file?

Matthew

I didn't think that I needed to point out that it was a Windows application.

No, you didn't, I understand your frustration completely... I was just pointing out how a real operating system might deal with the problem.

Matthew

In the past, I've had good luck using FireDaemon to run programs as a service that weren't designed for that purpose.

I agree that they simply don't know what they're doing in terms of windows programming and windows security. But if you're stuck using their product, FireDaemon can help.

Sorry. I'm clearly irony deficient right now.

It never ceases to amaze how poor the security engineering is of companies that claim to be in the business of security.

Yeah, FireDaemon costs money now. However, Microsoft provides instsrv and srvany in the resource kit and they do the same thing, albeit with a worse user interface. But even when I get it running as a service, which is honestly not that difficult with those tools, it requires that a user be logged in for it to function correctly and the "interact with desktop" checkbox be checked. As long as a user is logged in, it works fine. As soon as they log out, it stops working. If someone logs back in again, it works fine again.

They've done something to explicitly prevent it from working when no one is logged in. While connecting to it via VNC, I did actually notice that when it gets started with no UI, it actually pops up that window for an instant before making it go away, so that's probably the problem.

But now the problem is that it consumes large amounts of CPU even while it's doing nothing. I'd consider running it as a VMWare image, but if it's going to consume that much CPU regardless, I can't even do that. Maybe VMWare has a CPU throttle?

Yeah, I meant freebie VMWare. Hm. Does Linux have a per-process CPU limiter? I could limit VMWare itself.

Microsoft Virtual PC is free now too. Not sure if it could help...never used it.

I'm pretty sure it's VB, which would tend to make it more likely, I think.

I finally broke down, and, at least for now, set it up to autologin and put a shortcut to the program in Startup along with a shortcut to automatically lock the screen (rundll32.exe user32.dll, LockWorkStation). With the autolock in place, it won't start up properly. I have to go to the console and unlock the screen before it will start up properly. I suppose I can create a batch file to wait for a minute or so before it locks the screen, but, really? It won't start while the screen is locked?

Wow, that's pretty fscked up.

I also just discovered that it builds and tears down about four TCP sessions a minute, over which it seems to pass no, or at least very little, data.