Features of SvCom are as follows:
- Advanced service debugging directly from the IDE.
- Support of service failure actions
- DCOM support (DCOM server in Service)
- Enhanced support for DCOM objects: singleton model, apartment threading model, events support
- MIDAS server in service support
- Support of interactive service applications
- Configurable services support
- Message processing support
- Timer for services (Cool)
- Security-related non-visual components
- Security-related visual controls
- Logon/logoff detector
- Easy process enumeration (All in one function)
- Tools and utils
Debugging of SvCom-based services is far easier than debugging services created without SvCom.
The standard advice for service debugging using the Delphi VCL is to start your service from the Delphi IDE and then quickly start the service using Control Panel. This is a nice trick but it is not convenient and somtetimes it does not work (A service with DCOM server inside is a good example).
SvCom includes a powerful built-in service debugging tool. The idea of this tool is simple: if an SvCom-based application is started with the "/debug" switch it starts as an ordinary executable. Now the service will run in the debug mode exactly as it would as a service but this time you can trace it as an ordinary application.
Windows 2000 introduced a couple of new features for services: it is a service description and service recovery on failure. SvCom includes built-in support for all these features. You can specify any of allowed recovery operations: service restart, command execution or even computer reboot. Several recovery operations are allowed, Windows will execute the next one in the list after service failure will occur. The counter of failures can be reset to zero if the service works without failures for a given time interval. Use this properties to make your service more reliable - with SvCom it is easy now!
The SvCom includes it`s own ActiveX framework. It is partially based on native Delphi ActiveX framework but has some serious differences. All SvCom class factories know about SvCom services, this makes it possible to implement a DCOM server that will live in a service. SvCom takes care of all necessary registry keys and COM initialization. SvCom-based DCOM servers automatically support pausing and stopping, it is even possible to have several services in one application with several DCOM servers in each service. What’s more SvCom wizards make DCOM server in service creation as easy as possible.
Starting from SvCom 5.0 the DCOM support is essentially enhanced: now you can easy create DCOM servers that support events, allow creation of objects in apartment threads or use advances of singleton model.
MIDAS support is improved too. Now RemoteDataModules created to work in service correctly register themselves in registry which greatly simplifies the MIDAS-server-in-service creation.
The Delphi VCL was not designed to create interactive services. The reason being that it uses some system information that changes when interactive user logs off and logs on again. This will cause any forms that are created after a logoff/logon appear damaged.
SvCom includes component that protects service forms from being damaged even if logoff/logon occurs several times.
SvCom’s internal design allows several instances of one service module to be created and then used as independent services. Of course the names and some other attributes of each instance should be changed to avoid problems with operating system.
Note, that with Delphi’s service implementation it is not possible to use several instances of one TService descendant.
Standard services have no window handles at all, so the only way to send a message to this kind of service is to send it to the service thread. SvCom-base services do not have this limitation and are able to receive and process windows messages. Therefore it is possible to write a message handler for a service which will be called when the service receives the corresponding message.
SvCom includes specialized timer component that will work in a service. This automatically detects a service being started or stopped causing an OnTimer event to occur in the service thread. �Just drop it onto an SvCom service module and it is ready for use. If this component is dropped onto the form or an other module then it functions exactly the same as Delphi’s timer.
The Windows NT security model includes a lot of objects and rules concerning the use of these objects. Most of these objects are variable-length records and their manipulation is additionally complicated by memory allocations and deallocation.
This means that even simple tasks can require quite complicated code to accommodate the NT security model. Most of these objects are variable-length records and their manipulation is additionally complicated by memory allocations and deallocation. SvCom includes a set of components to deal with NT security objects such as SID, ACL, SECURITY_DESCRIPTOR and so on. In addition components are provided to control user privileges and access NT secret data storage. These components take care of the correct memory allocation for security objects and conversion of their representation. This greatly simplifies the manipulation of NT security objects.
SvCom’s non-visual security components provide an easy way to deal with NT security objects. Visual security-related SvCom components provide all levels of functionality that are necessary to design a user`s interface.
For example, SvCom includes the security descriptor editor dialog. This is a configurable component that can be used to adjust security of any NT securable object. It’s security-editing capabilities are much powerful then NT 4.0 and comparable with NT 2000.
SvCom includes non-visual component that detects when the interactive user logs on or off. There are no standard API to solve this task. Microsoft recommendation is to analyze the list of running processes to answer this question. This is the method is employed by SvCom.