[Solved] Daemon on Windows with updating display

[TyneBridges]

I'd like to write a computer booking application. It should run on Windows startup (that is,  before the user logs on) and read the PC status from a remote database. It needs to show the status in a banner on screen before logon and in a taskbar icon afterwards. ( I've done some work already on the database element.)

The obvious thing would be to create a Windows service using lazdaemon but I can see problems here with the banner and the icon, as this type of application seems to assume it will work without displaying anything.

Can I use an fptimer in a lazdaemon application, create a form without buttons or a close icon and a taskbar icon that I update using the timer?

I'd be grateful for any hints.

[BigChimp]

AFAIU/AFAIR, service (daemon) apps on Windows can have no interaction with the desktop. You'd have to write a separate program that communicates with the daemon.

Displaying something before logon will IIRC require modifying the GINA (pre Vista) or its successor.

Hope there are some people who have actually done more or less what you require to chime in with their experiences.

[TyneBridges]

Thanks for the information, BigChimp. It's not good news. I had hoped to avoid doing anything directly with the logon, as I gather writing your own logon GINA is extremely difficult and, it seems, Microsoft made it even harder from Vista onwards by completely rewriting its authentication model so that it no longer uses a GINA as such.

My aim is (or was) to create an alternative to a commercial application which I feel is very poor and crashes a lot in my organisation, particularly under Windows XP. I guess that, if this kind of thing was easy to write, they would have done it better... This was an experiment to see what I could do with Lazarus, a project I may now have to abandon.  :-(

Anyone know of any shortcuts?

[BigChimp]

There is pGINA, a project that provides various GINA options. You might want to use that/piggyback on that. Of course, that'll only do XP

As I said, I might well be wrong, so it pays to verify my.... hunches

[TyneBridges]

My application is meant to run mainly on Windows 7. I've had some clues from web searches but seem to be finding a lot of dead ends.  As BigChimp says,  it looks as if I need to use the service to start a GUI application (and then send messages to that via IPC). However, it seems that starting a GUI application from a service is also prohibited by Windows security in versions from Vista onwards. Does anyone know if this is true, and if there's a way round It? (I know I could try it out but would need more pointers to have a chance of getting anywhere. )

[gulyone]

if your deal is to launch a process able to contact a database engine over the internet at windows startup , i don't understand why you need to write a service.

service/daemon main purpose is to access low level hardware and are a kind of template for drivers writing. if you don't know exactly what you are doing at this level , the OS is going to be 'angry' around privileges and security attributes;

I suggest you to write an application, a standard one, and to make this application start each time a user opens a session on windows.

to do this , use the TRegistry class of Lazarus and the full path where ur application stands

In Windows Registry :

HKEY_CURRENTUSER\Software\Microsoft\Windows\CurrentVersion\Run contains a list of programs that are executed when the current user opens his session, so if your user installed your program, let your program write a value there , like 'MyApp' as name , 'c:\Program Files\MyApp\MyLaucher.exe' as value

no need of administrative rights at this level.. be careful in case of you want your app being launch for all users , use the
HKEY_LOCALMACHINE\Software\Microsoft\Windows\CurrentVersion\Run key
but your program will need administrative rights to write there

[TyneBridges]

if your deal is to launch a process able to contact a database engine over the internet at windows startup , i don't understand why you need to write a service.

service/daemon main purpose is to access low level hardware and are a kind of template for drivers writing. if you don't know exactly what you are doing at this level , the OS is going to be 'angry' around privileges and security attributes;

I suggest you to write an application, a standard one, and to make this application start each time a user opens a session on windows.

Thanks - that sounds like good advice, except that the program I'm trying to write is a computer booking application. That means it needs to show whether the computer is available or has already been booked, and whether the service point is open, before the user logs on. I don't need to prevent the logon as such because, if it's an "illegal" logon then I will just call the "ExitWindows" function. (This is not ideal but is the way our existing - and unreliable - commercial application works). The status does need to be shown before the user session starts, otherwise the user will be frustrated if he/she logs on when the computer appears to be available, and is immediately logged off.

[TurboRascal]

There are Startup, Shutdown, Logon and Logoff scripts on Windows. In this case, you could start your program as a Startup script and it will run as soon as the system finishes booting, but before the logon process starts; perhaps that's what you need? You can manage those scripts in the Group Policy editor.

Also as BigChimp said, desktop interaction is forbidden for services (daemons); it is tolerated in WinXP and earlier, but newer Windows are supposed to strictly enforce that.

@gulyone: there are some very good reason to use services other than those you mentioned, and it has roots in the ways daemons are often used on Unix. Namely, as on Unix systems users are normally unprivileged, the only way they can perform some tasks is to split applications into server part (daemon, running with root privileges) and client part which the user actually runs. (There is another way to deal with it, using suid binaries, but it's considered bad practice). It seems that similar architecture is already often used (also by M$ itself) on Windows to prevent some problems typical for older programs which expected administrator rights.

[TyneBridges]

There are Startup, Shutdown, Logon and Logoff scripts on Windows. In this case, you could start your program as a Startup script and it will run as soon as the system finishes booting, but before the logon process starts; perhaps that's what you need? You can manage those scripts in the Group Policy editor.

Thanks, TurboRascal. I think I need to do some experimenting to see if the principle of what I'm trying to do is possible without using a service. It's the pre-logon display where I can anticipate problems, but will try it out.

Edit: looks as if the difficult thing is that display. Whether I can use a startup script, or need to write a service that calls a GUI program, I will still have the issue that, until the user logs on, Windows does not start a desktop to display any program output...

(Later edit: I now know there is a desktop that can display program output - tagged as Winsta0\Winlogon. The difficult bit is accessing it. There has been "heated debate" on the forum about how I should do it. Writing a Credential Provider is much too difficult for me, so I'm continuing to look for the simplest solution.)

[BigChimp]

Having a virtual machine host that displays the booking info and restores a pristine running Windows snapshot showing the logon screen may be a solution... though perhaps a bit clunky and non-performant...
(Likewise for a terminal services server)

[gulyone]

1st of all , since windows vista , autoexec.bat is deactivated by default, so a script at startup would need to reactivate this

if you know well each of your users you can convince them to reactivate it , or you can convince them that your installed background service is not dangerous, but if you plan to distribute your app on a large users group, you are going to have some issues.

since im no more running an amstrad cpc64, some of my safe rules are as follow :

1) accept services/daemons only coming from well known and authenticated firms

2) never let programs reactivate stuffs that microsoft deactivated because of security holes

3) if one of the 2 above rules is broken, the application is instant thrown to the trash.

I much more trust my Ubuntu where I do not apply these basic rules

[BigChimp]

1st of all , since windows vista , autoexec.bat is deactivated by default, so a script at startup would need to reactivate this

Don't see what autoexec.bat has to do with this?

TurboRascal was talking about Active Directory/GPOs which enable scripts to be run (which are written by people with appropriate permissions to the AD e.g. domain admins).
I was talking about restoring running virtual machine snapshots.

John is talking about organizational use:

My aim is (or was) to create an alternative to a commercial application which I feel is very poor and crashes a lot in my organisation,

... so presumably he's got AD set up there and company IT can determine what can run on those machines, not the users.

[gulyone]

1st of all , since windows vista , autoexec.bat is deactivated by default, so a script at startup would need to reactivate this

Don't see what autoexec.bat has to do with this?

TurboRascal was talking about Active Directory/GPOs which enable scripts to be run (which are written by people with appropriate permissions to the AD e.g. domain admins).
I was talking about restoring running virtual machine snapshots.

John is talking about organizational use:

My aim is (or was) to create an alternative to a commercial application which I feel is very poor and crashes a lot in my organisation,

... so presumably he's got AD set up there and company IT can determine what can run on those machines, not the users.

permissions ? likewise fpcup ? on wich my antivirus (in the top 5 best of the wold) said kinda "OMG"?

[BigChimp]

Please stay on topic.

[gulyone]

Please stay on topic.

OK sir