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

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

Marcos Douglas B. Santos wrote

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

Actually, it could be a better idea. I will check the requirements and think if this would be possible.

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?

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 I didn't know these functions... sounds
a good option. Thanks.

Regards,
Marcos Douglas

Hey Martin, thanks to give me another good option. I'll check it.

Regards,
Marcos Douglas

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

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

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

Marcos Douglas B. Santos wrote

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.

Il 03/07/2018 15:14, Marcos Douglas B. Santos ha scritto:

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

On Linux environment, sample situation on one of our servers:

├─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

Very interesting!

Marcos Douglas