Forum > General

Daemon realization on Windows

(1/3) > >>

I tested the daemon realization in Lazarus under Windows and found that TDaemonDef uses UTF-8 strings (Name, Description and others) and they are directly passed to CreateService and ChangeServiceConfig2 winapi functions. Of course it works well only with Ascii symbols. I tried to change them manually using Move but failed probably because they are properties, not strings. Is it possible to make it work without rewriting all daemonapp unit?

You should not use that. Use the example that comes with FPC in rtl-extra.
Years ago Michael wrote a very good article about it. And it is still valid:

That should make it clear?

Thanks! But I have already read it two times and found no key differences with the daemonapp, maybe I missed something? As I said it works well on Windows (except when non Ascii symbols in the parameters). Under Linux there are some difficulties with SELinux that refuses to run my app as a daemon (I am investigating that yet)

Well, there's UTF8 again.
On windows, the strings should be unicode16 string and on linux utf8. (Ansi cp_utf8). These are compatible for FPC, so try to use unicodestring as string type in your windows service and UTF8 in your unix daemon.
That should solve the issue.
(Note on Windows, UTF16 has been the native api string type for decades, not years, Ansi is merely proxied... people tend to forget that or ignore it)
And don't use the component, but the class. The component is nonsense in this particular case.
Particularly today, I really do not understand the benefit of visual design for something that is non-visual.
Only for the controller it makes any sense.
This is nothing new: I hold this opinion for decades too. With maybe a small exception for the database access controls, that is.

I dont use the component either, just TCustomDaemon and TCustomDaemonMapper. but TCustomDaemonMapper uses the collection of TDaemonDef-s which in turn use UTF-8 strings as parameters. Should I throw it away and rewrite it using UnicodeStrings?
PS And I agree with you against visual components but it doesn't work with Delphi - its TService component cannot be used without a form, at lease i couldnt manage to get rid of it.


[0] Message Index

[#] Next page

Go to full version