Under
Windows NT and its sucessors (
Windows 2000,
Windows XP), services are the equivalent of a
unix daemon: a program that runs in the background, normally without
user interaction, independently of who is or isn't logged into the
computer.
What's the difference with a normal application?
A normal application is run when the user selects it from the start menu, clicks on its icon etc. When you close your windows session, all the applications you opened are closed for you. By contrast, a service may be running before you login (if it is set to start automatically) and will continue running after you logout. Any application you run will run "as you": they are able to access the same files as you and can do the same things as you. A service on the other hand can run as a different user than the currently logged in user.
What are they used for
Services are often used to provide services over the network, such as web serving, file and printer sharing or the messenger service (also known as winpopup, not to be confused with MSN Messenger). Other items are there to provide a service to your computer and need to run permanently, such as a DHCP client, a DNS client and probably some components of your anti-virus.The printer spooler for example is a service.
As you can see these are usually things that you want running all the time, irrespective of whether someone is using the computer or not. They also require little to no interaction.
Groovy! How do I use them?
The main interface for controlling services is via the the services control panel. In Windows XP this lives inside the Administrative tools section. From there you can see a list of installed and active services, add services, remove them, start them and configure various options. You set a user account (and the password to use for that account) that the service will use. You can also specify the LOCALSYSTEM account. This is a local administrator account, that has all privileges. When this is the account being used, it is possible to enable user interaction with the service, ie the service can display windows, have an icon in the system notification area (aka system tray) and generally interact with the user. However the LOCALSYSTEM account has no access to the microsoft network. You will not be able use things like mail slots (even if you are sending a message to the computer the service is running on), mount shared disks etc. Of course you can still access to normal tcp/ip networking.
It is also possible to control services from the command line. The command "net start my_service" starts the service called my_service, similarly "net stop my_service" stops it. You need to have configured the service first. There is an API for controlling and monitoring services so you can write your own tools to handle services from the command line.
So can any application be run as a service?
You can't use any old application as a service. Services have to be written specifically to be used as a service. Specifically services need to interact with the Service Control Manager and respond to a number of service specific messages from it. The Service Control Manager is in charge of keeping a list of all installed services, starting and stopping them, maintaining status information about services and other administrative tasks. It is possible to run as a service a program not designed as a service, with the utility srvany, but that's another topic for another node. Furthermore such services won't behave quite as normal services will. Additionally if an application is not expecting to be running at a time when there is no user logged in, hairy things may happen.
Process sharing
Services can also do something normal applications cannot. Services are frequently fairly small things that spend most of their time waiting, so it might be considered overkill for each one to have its own separate process, complete with 4GB address space. It is therefore possible to specify that your service can share a process with other services: the service control manager will group several services in a single process in order to save resources.
While this can be handy, it should be used with caution. For example if you have your own process it's fine to call ExitProcess() when you have finished or run into a non recoverable error, but if you are sharing a process then you may kill off several other services. In general you need to be very careful about calling functions that have process wide effects. Another consequence of sharing a process is that it is quite possible for you to trash other services sharing your process because you share the same address space. To sum things up you need to be careful, because if you screw up you may affect services other than your own.
Dealing with services pragramatically
It's possible to create services pragramatically, using the (surprise surprise) CreateService function. This function takes parameters equivalent to all the options you can set in the services control panel, such as the location of the executable, the account to use, how critical failure of this service is etc.
Programs can manipulate services with the ControlService function. This allows you to do things such as telling a service to start, stop or do more exotic things. You can also pass custom messages to your service. For example you might have a GUI which communicates with a service. Obivously your code needs to be running with adequate privileges in order to call these functions.