Software Metering
   C# Windows Application with MS Access Database

During the summer of 2005 LAN Technologies was in need of a way to do software metering in the public lab environments. There are several commercial solutions available, but most of them were big and bloated with far more features than we needed, not to mention expensive. We ended up selecting SofTrack because it was the only one we found that had a server component that ran on our Novell servers. We evaluated it on a small scale and it seemed to fit our needs pretty well, but after we purchased and implemented it, it has been a constant thorn in our sides. The configuration utility is a 16-bit poor excuse for a windows application. The reports take hours to generate (if you're lucky enough to get it to finish without crashing). The database is stored in a proprietary format that you must use their applications to access. And on top of all that it crashes our servers so often that we have to make sure it's only running on one node at a time. But this is not a review of SofTrack. The purpose of this is to tell you about the solution that Nathan and I decided to take on as a "pet" project that we did in our spare time at work called (for lack of any creativity) "Software Metering."

I had not done much C programming at the time so we decided to write in C# so that it could serve as a learning experience. The first step in this project was trying to figure out when processes were started and stopped in Windows. This doesn't sound like much, but it certainly took longer than any other aspect of the project. My first attempt simply involved constantly polling the task list and comparing it to the one just before like this...

This part is in VB because I was trying to write it quickly while Nathan was futzing around with this. While my way worked, it ate up a lot of CPU time and was prone to missing the occasional process launch. What Nathan was trying to do was use an NT Kernel mode driver that would actually trigger an event when an application was launched rather than having to poll. If you want more detail on how this works, check the link. It took a while for us to figure out how to actually use the driver, but eventually we (and by we I mean Nathan) wrote a dll in C that we could implement in our C# program. This fixed the pesky polling problem and we no longer missed any application launches.

Once that part was done, the rest was easy. Essentially, how it works is that once a process is launched, it connects to a database (in this case a very simple access database that you can see below) to see if that particular executable (or image) is among those being monitored. If not, it does nothing and allows the program to go on its merry way. If it is monitored, it looks up which package it belongs to and the total number of licenses for that package. Next it looks at the running table and computes the number of times that package is in use. If there are licenses available it allows the program to run and makes an entry into the running table. If not, it terminates the program and displays an error message. In code, that process looks like this...

A sample run of this application in the console with debugging enabled looks like this...

Here a few shots to give you an idea of the database design...

We only got into the preliminary stages of testing our program before we ran out of time and bought SofTrack, but we did get it working very reliably. I think the next step we wanted to take was to test it in just one lab. There are a few more tricky steps that I didn't mention, like cleaning up records for computers that didn't properly check out, but I can't give away all our secrets now can I? We always said we'd finish it someday and sell it, but somehow I doubt that will ever happen. I'll hang on to the code for a while just in case, Nathan.

This website and content therein Copyright © 2007 by Josh McCune