Discussion:
[fpc-pascal] Daemon using TTimer on Windows
Marcos Douglas B. Santos
2018-06-30 20:57:47 UTC
Permalink
Hi,

I need to build a daemon app on Windows. It will need a timer to
performe some tasks. This timer could be big among 15 min, 30 min, 2
hours, etc.

I thought that I can use TTimer but I've always heard that it's not
possible because some problems related with "NoGUI" stuff.

I've found a thread[1] which talks about that but they haven't
provided a real solution, at least for Windows.

My question is: Nowadays, can I use TTimer with no restrictions in a
daemon application on Windows? If not, which could be a possible
solution?

Thanks.

[1] http://lists.freepascal.org/pipermail/fpc-pascal/2013-March/036823.html

Best regards,
Marcos Douglas
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailma
R0b0t1
2018-07-01 00:13:26 UTC
Permalink
On Sat, Jun 30, 2018 at 3:57 PM, Marcos Douglas B. Santos
Post by Marcos Douglas B. Santos
Hi,
I need to build a daemon app on Windows. It will need a timer to
performe some tasks. This timer could be big among 15 min, 30 min, 2
hours, etc.
I thought that I can use TTimer but I've always heard that it's not
possible because some problems related with "NoGUI" stuff.
I've found a thread[1] which talks about that but they haven't
provided a real solution, at least for Windows.
My question is: Nowadays, can I use TTimer with no restrictions in a
daemon application on Windows? If not, which could be a possible
solution?
If all your service does is wait for the timer you should instead use
a scheduled task.

Anyway - does TTimer use the WM_TIMER message? That is the type tied
to the GUI. Even if you need to use WM_TIMER for some reason you can,
as services should be run in "session 0" and should have access to a
GUI. The latter is, I think, a compatibility option you can enable.

If you are not opposed to OS-level primitives you should use waitable
timers (https://docs.microsoft.com/en-us/windows/desktop/sync/using-waitable-timer-objects).
Using waitable timers you can also wake the computer from sleep.

Cheers,
R0b0t1
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pa
Marcos Douglas B. Santos
2018-07-01 13:06:07 UTC
Permalink
Post by R0b0t1
On Sat, Jun 30, 2018 at 3:57 PM, Marcos Douglas B. Santos
Post by Marcos Douglas B. Santos
Hi,
I need to build a daemon app on Windows. It will need a timer to
performe some tasks. This timer could be big among 15 min, 30 min, 2
hours, etc.
I thought that I can use TTimer but I've always heard that it's not
possible because some problems related with "NoGUI" stuff.
I've found a thread[1] which talks about that but they haven't
provided a real solution, at least for Windows.
My question is: Nowadays, can I use TTimer with no restrictions in a
daemon application on Windows? If not, which could be a possible
solution?
If all your service does is wait for the timer you should instead use
a scheduled task.
Actually, it could be a better idea. I will check the requirements and
think if this would be possible.
Post by R0b0t1
Anyway - does TTimer use the WM_TIMER message? That is the type tied
to the GUI. Even if you need to use WM_TIMER for some reason you can,
as services should be run in "session 0" and should have access to a
GUI. The latter is, I think, a compatibility option you can enable.
I didn't understand this "session 0"... is it a something related to
Lazarus or Windows?
Post by R0b0t1
If you are not opposed to OS-level primitives you should use waitable
timers (https://docs.microsoft.com/en-us/windows/desktop/sync/using-waitable-timer-objects).
Using waitable timers you can also wake the computer from sleep.
I'm not opposed at all. Indeed I didn't know these functions... sounds
a good option. Thanks.

Regards,
Marcos Douglas
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pa
R0b0t1
2018-07-01 16:44:19 UTC
Permalink
Post by Marcos Douglas B. Santos
Post by R0b0t1
Anyway - does TTimer use the WM_TIMER message? That is the type tied
to the GUI. Even if you need to use WM_TIMER for some reason you can,
as services should be run in "session 0" and should have access to a
GUI. The latter is, I think, a compatibility option you can enable.
I didn't understand this "session 0"... is it a something related to
Lazarus or Windows?
It is something related to Windows, and the reason services can not use the GUI.

A session is started for each terminal services instance. A session
contains multiple window stations, each of which contains at least one
desktop, one of which accepts keyboard/mouse input. One terminal
services instance exists by default, and it is the "local session,"
i.e. the one that consumes physical keyboard and mouse input and
outputs to the screen. It used to be that this local session was the
one that ran services in addition to logged in user programs.

This made it easier than it should have been to exploit service
processes, so they made session 0 noninteractive and now the console
logs in to session 1.

One exploit was particularly bad. You can forcibly register WM_TIMER
callbacks for an application and have that callback run in that
processes' thread. As long as services were running in the same
desktop you could trivially run code as SYSTEM.

More information at
https://blogs.technet.microsoft.com/askperf/2007/04/27/application-compatibility-session-0-isolation/
but it is not a lot. There is a better MSDN article I could not find.

Cheers,
R0b0t1
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepa
Martin Schreiber
2018-07-01 05:15:00 UTC
Permalink
Post by Marcos Douglas B. Santos
If not, which could be a possible
solution?
You could use a MSEgui application, instead of
"
uses
msegui;
"
write
"
uses
msenogui;
"
in "program" source file. It will have an event queue and the usual event
driven programming paradigm including the use of datamodules and graphically
placed non visual components. Examples are here:

https://gitlab.com/mseide-msegui/mseuniverse/tree/master/attic/msedocumenting/mse/trunk/help/tutorials/nogui

Martin
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/
Marcos Douglas B. Santos
2018-07-01 13:08:02 UTC
Permalink
Post by Martin Schreiber
Post by Marcos Douglas B. Santos
If not, which could be a possible
solution?
You could use a MSEgui application, instead of
"
uses
msegui;
"
write
"
uses
msenogui;
"
in "program" source file. It will have an event queue and the usual event
driven programming paradigm including the use of datamodules and graphically
https://gitlab.com/mseide-msegui/mseuniverse/tree/master/attic/msedocumenting/mse/trunk/help/tutorials/nogui
Hey Martin, thanks to give me another good option. I'll check it.

Regards,
Marcos Douglas
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cg
Marc Santhoff
2018-07-02 21:28:05 UTC
Permalink
Post by Marcos Douglas B. Santos
My question is: Nowadays, can I use TTimer with no restrictions in a
daemon application on Windows? If not, which could be a possible
solution?
Some years ago Graeme G. posted a solution to that problem. It's attached to
this mail, hoping hte list accepts pure text attachemnts, although I hoped it
would have been integrated in fpc/lazarus.

HTH,
Marc
--
Marc Santhoff <***@t-online.de>
Marcos Douglas B. Santos
2018-07-03 13:14:59 UTC
Permalink
Post by Marc Santhoff
Post by Marcos Douglas B. Santos
My question is: Nowadays, can I use TTimer with no restrictions in a
daemon application on Windows? If not, which could be a possible
solution?
Some years ago Graeme G. posted a solution to that problem. It's attached to
this mail, hoping hte list accepts pure text attachemnts, although I hoped it
would have been integrated in fpc/lazarus.
I've received the file, thank you.

Can we sleep a thread for minutes or even hours without any problems?
The OS will not kill the thread?

Regards,
Marcos Douglas
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.free
Marc Santhoff
2018-07-03 13:46:31 UTC
Permalink
Post by Marcos Douglas B. Santos
Can we sleep a thread for minutes or even hours without any problems?
The OS will not kill the thread?
Sorry, I simply don't know. Try it.
--
Marc Santhoff <***@web.de>
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/ma
Giuliano Colla
2018-07-03 14:36:38 UTC
Permalink
Post by Marcos Douglas B. Santos
Can we sleep a thread for minutes or even hours without any problems?
The OS will not kill the thread?
├─hald───hald-runner─┬─hald-addon-acpi │ ├─hald-addon-keyb │
└─2*[hald-addon-stor]
16:27:34 up 567 days, 20:40, 1 user, load average: 0.02, 0.01, 0.00
Hald threads are unused since 567 days (they're triggered by the
insertion of new hardware, which never happened on our server) and are
still there!

On Windows a CTRL-ALT-DEL will show you a lot of useless threads
activated at power on, and sleeping since then.

OS may decide to swap them off, so that activation may be slower, but
never to kill them.

Giuliano


_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepas
Marcos Douglas B. Santos
2018-07-03 17:21:56 UTC
Permalink
On Tue, Jul 3, 2018 at 11:36 AM, Giuliano Colla
Post by Marcos Douglas B. Santos
Can we sleep a thread for minutes or even hours without any problems?
The OS will not kill the thread?
├─hald───hald-runner─┬─hald-addon-acpi │ ├─hald-addon-keyb │
0.02, 0.01, 0.00
Hald threads are unused since 567 days (they're triggered by the insertion
of new hardware, which never happened on our server) and are still there!
On Windows a CTRL-ALT-DEL will show you a lot of useless threads activated
at power on, and sleeping since then.
OS may decide to swap them off, so that activation may be slower, but never
to kill them.
Very interesting!

Marcos Douglas
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pa

Loading...