Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

WM_ENDSESSION - how to continue shutdown ?

293 views
Skip to first unread message

R.Wieser

unread,
May 1, 2017, 5:43:08 AM5/1/17
to
Hello All,

I've got a program which has a rather time-lengthy WM_ENDSESSION (system
shutdown) procedure, and I'm wondering how to, after it has finished, tell
the system to proceed with the shutdown.

I could just execute another system shutdown, but am wondering if there
isn't something build-in which does that job.

Also, when I have to run another system shutdown than how should I protect
my app from receiving it too* (and restart the lengthy WM_ENDSESSION
procedure) ? I could execute a PostQuitMessage, but I could imagine that
causing a race condition (between the actual quitting and another
WM_ENDSESSION being received -- which would be bad).

*I could ofcourse introduce a flag which gets set at the end of the
WM_ENDSESSION procedure and tested/used by WM_QUERYENDSESSION to see if the
shutdown should be cancelled or not, but if thats not needed than is just
extra work for nothing. :-)

By the way: MSDN mentions nothing in that direction, and neither did some
googeling turn up anything in this regard ...

I almost forgot: Its for Win98se (if that makes any difference).

Regards,
Rudy Wieser



JJ

unread,
May 1, 2017, 8:25:48 AM5/1/17
to
On Mon, 1 May 2017 11:44:17 +0200, R.Wieser wrote:
> Hello All,
>
> I've got a program which has a rather time-lengthy WM_ENDSESSION (system
> shutdown) procedure, and I'm wondering how to, after it has finished, tell
> the system to proceed with the shutdown.
>
> I could just execute another system shutdown, but am wondering if there
> isn't something build-in which does that job.

There's none, for both.

Windows WM_QUERYENDSESSION is more of a notification rather than a query,
because if an application doesn't respond within 5 seconds, it would treat
the application as unresponsive, and will still proceed the system shutdown
procedure anyway.

> Also, when I have to run another system shutdown than how should I protect
> my app from receiving it too* (and restart the lengthy WM_ENDSESSION
> procedure) ? I could execute a PostQuitMessage, but I could imagine that
> causing a race condition (between the actual quitting and another
> WM_ENDSESSION being received -- which would be bad).
>
> *I could ofcourse introduce a flag which gets set at the end of the
> WM_ENDSESSION procedure and tested/used by WM_QUERYENDSESSION to see if the
> shutdown should be cancelled or not, but if thats not needed than is just
> extra work for nothing. :-)

That flag is required if your application is the one that initiates the
system shutdown, and your application needs to know whether a system
shutdown was initiated by itself or not. Simply because neither
WM_QUERYENDSESSION or WM_ENDSESSION includes information regarding which
application initiated the system shutdown.

> By the way: MSDN mentions nothing in that direction, and neither did some
> googeling turn up anything in this regard ...
>
> I almost forgot: Its for Win98se (if that makes any difference).

Doesn't make a difference, really. Even all the new functions in NT, XP,
Vista+ doesn't provide a way to pause a system shutdown. You can either
allow or reject. You can delay but only for 5 seconds.

R.Wieser

unread,
May 1, 2017, 8:38:42 AM5/1/17
to
JJ,

> There's none, for both.

Thats the notion I aso got, but wanted to make sure.

> That flag is required if your application is the one that initiates the
> system shutdown,

Why ?

As I mentioned, I thought I could just close the app thats restarting the
shutdown process, and by it simply "not be there" when the new round of
WM_QUERYENDSESSION / WM_ENDSESSION is fired off. In that case such a flag
would not help in the slightest.

> Doesn't make a difference, really.

After having read the MSDN and some other sites about it I didn't think so
either, but who knows ... :-)

Regards,
Rudy Wieser





-- Origional message:
JJ <jj4p...@vfemail.net> schreef in berichtnieuws
zqg5lwv3bvc2$.ig6bnakehci4.dlg@40tude.net...

JJ

unread,
May 2, 2017, 2:05:38 PM5/2/17
to
On Mon, 1 May 2017 14:40:04 +0200, R.Wieser wrote:
>
> Why ?
>
> As I mentioned, I thought I could just close the app thats restarting the
> shutdown process, and by it simply "not be there" when the new round of
> WM_QUERYENDSESSION / WM_ENDSESSION is fired off. In that case such a flag
> would not help in the slightest.

Oh right. I forgot that we can do that hit-and-run method. At least,
assuming that we have full control of our window message handler, or exits
the thread immediately after initiated the system shutdown.

R.Wieser

unread,
May 2, 2017, 4:56:19 PM5/2/17
to
JJ,

> Oh right. I forgot that we can do that hit-and-run method.

Ah, gotyou. You also have no idea other than to use that flag. No
problem, maybe someone else does.

As for your sarcasm ? Stuff it. I described both the flag possibility as
well as the race condition to show that I'm aware of both, but was out for a
bit of info, like maybe a tip to how the latter has a common way to be
handled. Something like a "terminate app *NOW*" command that I could
execute directly after ExitWindowsEx.

Now I think of it, I could possibly use ExitThread for that. Hmmm...

Regards,
Rudy Wieser


-- Origional message:
JJ <jj4p...@vfemail.net> schreef in berichtnieuws
1a8imix8qzaf3.1...@40tude.net...

JJ

unread,
May 3, 2017, 8:18:47 AM5/3/17
to
On Tue, 2 May 2017 22:57:41 +0200, R.Wieser wrote:
> I described both the flag possibility as
> well as the race condition to show that I'm aware of both, but was out for a
> bit of info, like maybe a tip to how the latter has a common way to be
> handled. Something like a "terminate app *NOW*" command that I could
> execute directly after ExitWindowsEx.

Would be best to cleanup everything before calling ExitWindowsEx() and bail
out, so that there would be minimal time required to actually exited the
current process.

> Now I think of it, I could possibly use ExitThread for that. Hmmm...

That, assuming the application is not multi threaded, or doesn't use any DLL
that spawn a new thread by itself. Otherwise, it'd be safer to use
ExitProcess().
0 new messages