Windows Services (formerly known as NT Services) can seem overwhelming and daunting to the uninitiated because of a vast array of callback functions and long parameter lists. Even though creating services in C++ almost ensures top-notch performance, the complexity factor might outweigh that fact. However, with the recent release of the .NET Framework SDK, the complexity of creating and controlling services has diminished. If development time is of the essence, Visual C#.NET and the .NET Framework prove invaluable assets.

What you need:
.NET Framework SDK, Windows NT4 or Windows 2000   



In this article, I'll demonstrate the necessary steps to create a Windows Service, then explain how to control your service by creating a useful utility that could prove invaluable as you test and debug your service. But first let me give you some background on Windows Services.

Most of us remember terminate-and-stay-resident (TSR) programs—ones that remained in memory after being executed but gave control back to the user. As useful as they were, you faced the occasional compatibility problem in the environment you ran them in. System architectures inevitably increased in reliability and multitasking capabilities, and the TSR gave rise to what we now call the service.

A service is an executable that gives the operating system nonintrusive functionality. A service installed and configured to run automatically begins execution before a user logs on to the computer. Some common uses for services include hardware control and monitoring applications; system-level utility, diagnostic, and reporting tools; and communication software such as a Web or file-system server.

Although a service is an executable, you can't start and terminate it through traditional means. The first and most common way to start one: Register it with the Service Control Manager as an automatic service. This ensures the service starts as soon as the machine has finished the boot cycle and before a user logs on to the system. You can also start a service manually using the console command NET START <servicename> or through the service applet within the Windows Administrative tools group.

Services also can allow you to pause and continue during execution, either manually or programmatically. But providing this functionality is up to the service designer—it's not required.

Just as a service doesn't start as other executables do, it also can't terminate the same way many other executables can. The service itself generally has no user interface associated with it, so it terminates when the user turns off or restarts the system, or manually stops the service using the service applet again or with the NET STOP <servicename> console command.

You must follow special rules while creating a service to get it to run correctly within the system environment. The most important: You must install or register a service within the system it intends to run in. In other words, you can't just run a service by double-clicking on its executable file. Furthermore, a service shouldn't provide a user interface. Rather, it should do its reporting with the system event log or performance counters. I'm not saying services can't have a user interface, but each service is created within in its own Windows station, so UI-related API calls might not succeed. Finally, a service must support a number of methods I'll discuss later to control its execution life cycle.