Most programs require that a user log on to the system to run them. However, long ago before Windows ever appeared, UNIX developers realized the importance of having some programs run from the time that a computer booted until the computer was shut down because the programs provided important services that had to run, even when nobody was logged on. Hence, the daemon was born. A daemon is software that's designed to run at boot time and keep running, without user intervention. The OS launches the program because a user might not be available to do so.
Most of the common services associated with the Internet are daemons, such as Web, FTP, email, firewall, streaming-media, and print services. These services start running when the computer starts and stop running when the computer shuts down.
Windows OSs based on the Windows NT kernel (e.g., Windows Server 2003, Windows XP, Windows 2000, NT) refer to daemons as services. You can find your machine's Win32 services and their states (e.g., running, stopped) in the Control Panel Services applet, which is in the Control Panel's Administrative Tools folder. When you double-click the Services applet, the Microsoft Management Console (MMC) Services snap-in appears. The Services snap-in lists each service's name and provides information about that service, such as its description and status.
Win32 services are useful for many reasons. For example, Win32 services provide the means to run a program when the OS starts. In addition, you can control a service from a remote machine.
You can make almost any application or tool a Win32 service. For example, consider a script that pings a server every minute to determine whether the server is online. This script is a perfect candidate for a Win32 service because it needs to run as soon as the OS is loaded and must continue running regardless of which users log on and log off.
Win32 services are truly great tools. However, when you use C or Visual Basic (VB) to develop them, the task is fairly daunting because you have to manage multiple threads interacting at different times. This task leaves you with little time to benefit from the services. However, you can use a Perl script to create Win32 services, which is far easier than using C or VB to create them. And modifying a service is as easy as modifying a Perl script.
How Win32 Perl Services Work
Windows uses a specialized software manager called the Service Control Manager (SCM) to handle services. The SCM manages the state of a service. When Windows boots up, the SCM starts any service configured to start at boot time. When a user wants to start, pause, or stop a service, the SCM performs the action on the user's behalf. The SCM then interacts with the service to inform it that its state must change.
When the SCM starts a service, the SCM executes the service's .exe file. For Perl scripts, the SCM launches perl.exe and passes to perl.exe the name of the Perl script and any parameters that the script needs. The Perl script then tells the SCM to treat it as a service. Thereafter, the script is officially considered to be running as a service. In addition to whatever tasks the script is programmed to do, the script has only one service-related task that it must perform: monitor the SCM for state changes.
The SCM receives requests to change the state of a service. Such requests can come from not only local or remote users but also local or remote applications and system components. Thus, the Perl script continuously monitors the SCM for state changes and reacts accordingly. For example, when the state changes to SERVICE_PAUSE_PENDING, the script reacts by performing whatever actions are required to make the script pause. The script must then inform the SCM that it has entered the SERVICE_PAUSED state. The script reacts similarly to the SERVICE_START_PENDING, SERVICE_CONTINUE_PENDING (essentially unpausing), and SERVICE_STOP_PENDING states and performs the necessary actions to enter the pending state.