The file I have linked to above can be used to replace the official Services segment as it is in working order and does not require any extra plugins. It works with both ANSI and Unicode variants of NSIS and handles system architecture properly. It supports the use of handling services in the launcher.ini file (
[Service2]). It has debugging support for those who want to debug this segment when making a portable of an application that ues Windows Services. The file is also commented for those who would like to know the play by play in the code.
USAGE: To make use of this segment, add the section [Service1] (numerical ordering) to the Launcher.ini file. Each entry supports six keys which are as follows: Name - The local/portable service name. Path - The path to the portable service executable. Supports environment variables. Type - Specify whether you are dealing with a service, a kernel driver or a file system driver, etc. Choose from: own, share, interact, kernel, filesys, rec Start - Specify when the service is supposed to start. Choose from: boot, system, auto, demand, disabled, delayed-auto Depend - List any dependencies here separated by / (forward slash). IfExists- You can either skip or replace the service if it already exists. Choose from: skip, replace EXAMPLE: [Service1] Name=ServiceName Path=%PAL:DataDir%\drivers\service.sys Type=kernel Start=system Depend= IfExists=replace
For those of you who would like to see this file working in action, a working implementation can be seen with the development test release of Emsisoft Emergency Kit Portable. If you're curious about how it works, open the Services.nsh file and the EmergencyKitPortable.ini.
I would love to see some feedback on this new segment file as I'm sure there could be bugs within the code somewhere. It's always good to have an extra set of eyes other than your own.