The server programs in Chapters 11 and 12 were console applications written to
run in the background . In principle, the servers could run indefinitely, serving
numerous clients as they connect, send requests, receive responses, and
disconnect. That is, these servers could provide continuous services, but to be fully
effective, the services must be managea ble.
previously known as NT Services, provide the management
capabilities required to convert our servers into services that can be initiated on
command or, at system boot time, before any user logs in, and can also be paused,
resumed, and terminated. Services even make i
t possible to monitor the health of a
service. Information about services is maintained in the registry.
Ultimately, any server system, such as those developed in Chapters 11 and 12,
should be converted to a service, especially if it is to be widely used by customers
or within an orga
Windows provides a number of services; examples include the telnet, fax, a nd
security accounts’ management services as well as device drivers. There is an
administrative tool, accessible from the control panel, that will display the full set
(Program 6–3) provides rudimentary server manage-
ment by allowing you to bring up a server under job control and send a termina-
tion signal. Wi ndows Servi ces, however, are much more comprehensive and
robust, and the main example is a conversi on of
so that it can control
This chapter also shows how to convert an existing console applicati on into a
Windows service and how to install, monitor, and control the service. Event
logging, which allows a service to log its actions, is also described.
This terminology can be confusing as the Windows systems provides numerous services that are not
the Windows Services described here. However, using the term “Windows” throughout the book when
talking specifically about the API is equally confusing.