SvCom - Services 64bit on Delphi 11.3

[FPessina 0]

Hello,
I am using the SvCom library to develop windows services.

On Delphi 11.3 with target platform Win32 it works, but I am unable to let services run with target platform Win64.
On Delphi 10.4 everything worked fine.

I checked source code of the library and It seems that nothing significant has changed between the two versions.

The problem is that, when the service starts, an error is being displayed on svCom window (No exception is raised):

SetServiceStatus: hServiceStatus is invalid

Then the service just stop.

The code that should set service status, and that return the error is the following:
 

const PSvSetServiceStatus: Pointer = nil;
function SvSetservicestatus;
asm
call InitNTServiceDebug
{$IFDEF CPUX64}
Mov rax, qword PTR [PSvSetServiceStatus]
test rax,rax
Jz SetServicestatus
Jmp dword64 Ptr [PSvSetServiceStatus]
{$ELSE}
Pop EBP
Cmp DWORD Ptr [PSvSetServiceStatus],$00
JZ SetserviceStatus
jmp DWORD Ptr [PSvSetServiceStatus]
{$ENDIF}
end;

I also tried to contact the support of this library but received no reply
Do you know how this could be fix?

Thanks

[ErikP 0]

Same for me and no more support from SVCom.

I have switched to DDService.  I took me a little time to convert my project.  

Debuging is more complicated so I write a Win64 app first.  When tests are done, I switched to DDService.

Service is stable.

[Angus Robertson 577]

SVCom is better than DDService in it's support for interactive applications with lots of VCL components.  DDService fails to start if the form contains some third party components, but seems mostly fine with simple components, memo, edits, buttons, etc. So there is come magic going on in the modified forms unit that SVCom uses. 

 

But I was always concerned about long term support for new compilers, since SvCom has obscure licensing checks which is why I've been updating and supporting DDService for several years and now use it for all my server applications. 

 

Angus

 

[FPessina 0]

So there is no way to let services compiled with D113 run on Win64 with SvCom?

[Angus Robertson 577]

Sorry, can not tell you that, I never bought a copy of SvCom that would run on modern compilers, no idea if they still issue updates for new compilers.  It was a good product in it's time, but despite coming with source code it still had some licensing magic that might never be updated for new compilers, so risky long term.

 

Angus

 

[Anders Melander 1815]

I've written many, many Windows services and never encountered anything that couldn't be satisfied with the standard Delphi service classes.

 

I'm curious; Why is it that you need to use SvCom at all?

[Angus Robertson 577]

The main advantage of SvCom was being able to create dual GUI/service applications, so you can run your service in the IDE under the debugger, often with a few VCL controls, and also install it as a service and run it in the background. 

 

One of my applications runs as both a service and GUI at the same time, depending on how the client configures it, with the two instances communicating, so the GUI shows everything the service is doing, it has a very complex GUI.  

 

DDService can be used similarly, but is less forgiving about the controls and the service will not start when certain third party controls are used. 

 

Debugging an application using TService, etc means a lot of logging or generally have a GUI test application to debug the main code. 

 

Angus

[Remy Lebeau 1436]

56 minutes ago, Anders Melander said:

I've written many, many Windows services and never encountered anything that couldn't be satisfied with the standard Delphi service classes.

Agreed.

39 minutes ago, Angus Robertson said:

The main advantage of SvCom was being able to create dual GUI/service applications, so you can run your service in the IDE under the debugger, often with a few VCL controls, and also install it as a service and run it in the background. 

I've written many services, but I have written only 1 service that ever needed to run in dual GUI/service modes, and even then I eventually broke out the GUI into a separate project that communicates with the service.

39 minutes ago, Angus Robertson said:

One of my applications runs as both a service and GUI at the same time, depending on how the client configures it, with the two instances communicating, so the GUI shows everything the service is doing, it has a very complex GUI.

All the more reason to break out the GUI into its own project, to reduce the complexity of the service project.

39 minutes ago, Angus Robertson said:

Debugging an application using TService, etc means a lot of logging or generally have a GUI test application to debug the main code.

Not really.  The IDE debugger can be attached to a service process.  If I ever need to debug a service's startup code, I simply define a command-line parameter that I can issue in the SCM, and then I have the TService.OnStart event handler look for that parameter to invoke a pause until I attach the debugger to the process.  Then I can debug the remaining startup code normally.

[Fr0sT.Brutal 900]

I wonder how components could cause troubles when running in service mode? The form shouldn't be created at all so they won't exist.

[FPessina 0]

20 hours ago, Anders Melander said:

I'm curious; Why is it that you need to use SvCom at all?

We use SvCom to be able to use their service manager simulator, which is convenient for debugging.
In addition, we have about 20 services developed with SvCom, and refactoring them all to stop using it would take a lot of time and effort.

 

19 hours ago, Remy Lebeau said:

Not really.  The IDE debugger can be attached to a service process.  If I ever need to debug a service's startup code, I simply define a command-line parameter that I can issue in the SCM, and then I have the TService.OnStart event handler look for that parameter to invoke a pause until I attach the debugger to the process.  Then I can debug the remaining startup code normally.

This could be an effective method for debugging services, but I personally find it more inconvenient than having a servicemanager simulator like with SvCom (if only it worked with win64).

if no solution is forthcoming, we will consider this approach by converting all services to TService.

[FPessina 0]

We found the solution!

The problem seems to be the "Address space layout randomization", a new feature introduced in Delphi 11.

You can find it on Project Options -> Building -> Delphi Compiler -> Linking: Here are two options:

• Support address space layout randomization (ASLR)
• Support high-entropy 64-bit address space layout randomization (ASLR)

These two options are set to TRUE by default on new projects.

 

SvCom uses assemblies, which is probably why it fails when ASLR is enabled.
By disabling even just one of these two options, everything goes back to working as it should.

 

Hope this can help other people who might have problems with SvCom or even just with assembly code on Delphi 11.

 

[Fr0sT.Brutal 900]

What's the point of pushing ASM into elementary API calls? What's the point of ASM not inside speed-critical routines?

[Remy Lebeau 1436]

13 hours ago, Fr0sT.Brutal said:

What's the point of pushing ASM into elementary API calls? What's the point of ASM not inside speed-critical routines?

I don't have SvCom's source code to look at, but offhand I would appear that SvSetservicestatus() is acting as some kind of proxy and is using ASM to preserve the original call stack when jumping into other functions, rather than pushing its own data onto the call stack using normal function calls.

Edited June 21, 2023 by Remy Lebeau