LocalService
Allows an object
to be installed as a Win32 service.
Registry Entry
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\APPID\
{ AppID_value}\LocalService
= service_name
Remarks
In addition
to running as a local server executable (EXE), a COM object may also
choose to package itself to run as a Win32 service when activated by a local or
remote client. Win32 services support numerous useful and UI-integrated
administrative features, including local and remote starting, stopping,
pausing, and restarting, as well as the ability to establish the server to run
under a specific user account and Window Station, and optionally interactive
with the desktop.
An object
written as a Win32 service is installed for use by OLE by establishing a LocalService
named-value under its CLSID
key and performing a standard service installation (refer to the Win32
documentation and the SECSVR distributed COM sample application for more
information on writing, installing, and debugging Win32 services.). The LocalService
named-value must be set to the service name - as configured in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services - as the default REG_SZ value.
Additionally,
when LocalService is set, any string assigned to the named REG_SZ value,
ServiceParameters,
will be passed on the command line to the service as it is being launched.
For example,
the following keys register the c:\mydb\mydb.exe executable to launch as the
MyDatabase service when activated remotely. When launched as a service, the
process receives -Service on its command-line.
HKEY_CLASSES_ROOT\APPID\{ c5b7ac20-523f-11cf-8117-00aa00389b71}\LocalService
= MyDatabase
HKEY_CLASSES_ROOT\APPID\{ c5b7ac20-523f-11cf-8117-00aa00389b71}\ServiceParameters
= -Service
The service
configuration is preferred in many situations where the capabilities of the
local and remote service management APIs and user interface might be useful for
the services that the object provides. For example, if the object is
long-lived, or readily supports concepts such as starting, stopping, resetting,
or pausing, leveraging the existing administrative framework of the service
architecture should be an obvious choice.
Services can
be dynamically configured using the Services application in the Control
Panel, and can be configured to run automatically when the machine boots, or to
be launched when requested by a client application.
There are
several additional points you should be aware of if you are implementing
classes as services:
The LocalService
named-value is used in preference to the LocalServer32 key for local and remote
activation requests - if LocalService
exists and refers to a valid service, the LocalServer32 key is ignored.
Currently only a single
instance of a Win32 service may be running at a given time on a machine. OLE
services must therefore register their class objects on launch using
REGCLS_MULTIPLEUSE to support multiple clients.
OLE services configured to run
automatically when a machine boots must include RPCSS in their list of
dependent services in order to launch and initialize properly.
Although services may be
configured to interact with the interactive user, they are always run in a
separate window-station and desktop from the interactive user.
This prevents service processes from being automatically terminated when the
interactive user logs off.
See Also