[RESOLVED] Disallowing user to run application

[hypheni]

dll ?.. How a dll would kill and restart an application ?.

[John E]

Similar to the suggestion by Mr Viggy. The updater could be written so that it would check for the existence of something that either got created or installed by the DLL. Because users can't run a DLL directly, this "something" could only exist if the main app triggered it. For example, the DLL could install a Windows service. Whenever the updater ran it would check to see if the service was running and would exit if it wasn't.

Or if the updater didn't need to have a GUI, the updater could be a service in its own right, installed by your main application or one of its DLLs.

The bottom line is that the updater needs to check for something that will only be present if the main app has somehow provided it. The main app can run a particular DLL which can be used to communicate between the main app and the updater. Or some other comms methodology could be set up (a pipe or socket connection maybe). Or the main app could install a Windows service. Or it could provide some undocumented command line parameters known only to it and the updater.

[Igor Vartanov]

dll ?.. How a dll would kill and restart an application ?.

Dll itself would not. A surrogate process running the dll would do alright. rundll32 perfectly fits this schema (running the dll which checks parent process )

BTW, "kill an application"... I really hope you meant "gracefully shut down"

[John E]

That's an excellent suggestion from Igor. It would allow you to write your installer as a DLL which your main app could spawn using rundll32. A power user (such as you) could also run it the same way (say, for testing purposes) but most average users wouldn't think of running it that way.

[hypheni]

Yeah, nice idea Igor.

I will defining try it out, and sadly I didn't gracefully shutdown the main application. I used TerminateProcess.

Correct me where I am wrong.

[Igor Vartanov]

... and sadly I didn't gracefully shutdown the main application. I used TerminateProcess.

Correct me where I am wrong.

Well, it's obvious. Your application surely have an Exit. So what's difficult in calling Exit on a signal from outside? In one of my projects I implemented the following: a dedicated thread starts and gets to wait on a named event. On waking up on the event the window message is sent to main window with the Exit command (menu command id in fact). Installer while running signals the event and waits until process quits. Nice and easy. Of course, the event is created for admin access only, and has a global namespace, as my main app is able to run both modes, interactive and service.

[hypheni]

Yes, my applications exit means a call to PostQuitMessage(0) and some cleanup codes. So I need to send a WM_QUIT message on receiving the signal.

Right ?

[Igor Vartanov]

As long as some cleanup is required it would be better make the exit go usual way. If PostQuitMessage + cleanup occurs on WM_CLOSE, you need to send WM_CLOSE to your main window. Hope this is clear enough.