The Old New Thing

"And of course, you can't close a disabled window."

I don't think this is true.  Disabling a window prevents the window from receiving UI events; it doesn't seem to restrict what can be done to a window programmatically.  I just wrote a test program to verify this.

I think this is the cause of an annoying quirk in Windows: a disabled window can be activated from the taskbar.

PhilQ - surely all the behaviour you've described is just what you'd want the system to do. Imagine if disabling a window caused all window calls to fail or block. What could you do with the disabled window then?

And you want a disabled window to be activatable from the taskbar because people may still want to look at the app, even if it isn't ready for interaction.

That's funny, I was just reading this: http://blogs.msdn.com/michen/archive/2008/04/04/Application-termination-when-user-logs-off.aspx yesterday.

I managed to get the Visual Basic Express 2008 window to disable itself so I had to kill the process.  Very annoying.

Protip: Don't try to build a project while debugging, and if you do, don't click "Yes" when it asks if you want to stop debugging.

I checked how .NET handles WM_QUERYENDSESSION and WM_ENDSESSION.  Although I'd have to take .NET Reflector to check the code itself, from a quick look at events and help files it seems .NET just triggers FormClosing and FormClosed on all open forms, respectively (and I assume it calls Application.Exit() which triggers its own event and cleanup stuff too).

I found the key help article here, under the CloseReason enumeration which is sent as part of a FormClosing event (FYI you need VS2008 installed to use this URL):

ms-help://MS.VSCC.v90/MS.msdnexpress.v90.en/fxref_system.windows.forms/html/fa4621f4-6474-21d1-841a-13b1e31e62a8.htm

I'm guessing "WindowsShutDown" would be what is sent in this case (since, to programs running in a user session, that user logging off is no different from a system shutdown... they shouldn't care about the difference, anyways).

I'm a bit curious how they differentiate between some of those cases... I guess TaskManagerClosing happens when .NET gets a WM_CLOSING message that .NET knows it didn't trigger itself.  The rest are internally generated I guess.

Raises the topic of what I consider to be one of the worst dialogs in windows. When shutting down if an app pops up a 'save ur work?' dialog the windows pops up a 'this app is dead - kill it?' dialog after a short time.

THis dialog is *guaranteed* to hide the first dialog. Most users dont now to move this dialog aside, so they just hit 'kill it'.

I have seen this so many times. THye end up loosing their work

All that windows needs to do is pop up the kill it? dialog not in the center. Or ideally it should recognize this common case and say "this app is asking you a question - please answer it"

This weekend I was cleaning gigabytes out of my temp folder, wondering how all this junk gets left behind.

Programmers who don't understand Windows shutdown may be part of the problem.

If you rely on the RAII (Resource Acquisition Is Instantiation) pattern, then you have to make sure your destructors actually get called.  In the normal flow of things, C++ offers a lot of guarantees on this.  But getting your process terminated at shutdown voids those guarantees.

Like Raymond says, lots of that cleanup is pointless when the user is logging off, but some of it isn't.  Flushing buffers, saving preferences and documents, and deleting your temp files aren't optional.  If you rely on RAII, then you have provide a way for all of those important destructors to run on WM_ENDSESSION.

Another problem is the I/O contention at shutdown.  With the mad rush of programs trying to scribble data on the disk, you're lucky if you can write a couple sectors before your five seconds expires.

On a related question, how does Task Manager kill an application when you choose End Task?  Does it ask nicely before resorting to TerminateProcess()?

Many apps just use MessageBox for the purpose of asking whether to save or not before closing. It would probably be sufficient to detect that. Otherwise, just pop up the "Kill?" window somewhere other than center, such as top-center.

Solving this problem would involve taking a radically different approach: Abandon the notion that you need to offer to kill any app which isn't quitting. There's a difference between apps which choose not to quit (because the user hasn't saved a document yet or what-have-you) and apps which cannot quit (because they've gotten themselves into a buggy state from which they cannot recover). Windows conflates the former with the latter, and that's not only annoying but arguably dangerous.

But I really jumped into the comment-stream of this post for another reason: For a while now I've wondered where in Windows I could find something like the "quit" event on Mac OS. (Apple Events differ from Windows messages in that Apple Events are sent to an application rather than a window.) Here are the candidates I've encountered so far:

WM_QUIT isn't a real message and shouldn't be sent by one application to another. (If you are doing this, you need to read more entries on this blog.)

WM_CLOSE has the scope of a single window rather than an app, so if you're going to use it to mean the app should quit, then you need to designate a special (hidden) window which listens for this message and the sender needs to know to seek out this window (which is what I have done so far).

WM_DESTROY is obviously wrong; don't get me started.

WM_ENDSESSION seems to be intended to be sent by the system rather than an application.

Any clues for me, RC?

"[And then you'd be punishing programs that used the new task dialog interface. Sure, you can add that to the list, but what do you do when the next version of Windows adds a new, improved interface? Do you issue a patch for Windows Vista to recognize the new interface, too? -Raymond]"

But why would Vista need to be concerned with the new interface features?  Let's say we had such a function in XP that detected message boxes.  Obviously in Vista, there are TaskDialogs as well.  But why would XP have to be concerned with TaskDialogs, when you can't show TaskDialogs on XP?

Of course, it's a matter of priorities. If you prioritize the "I can't shut down" case, then you can't prioritize the "save this document?" case.

If you prioritize the former, than you are stopping some whining, and if you prioritize the latter, then you are protecting data.

I know which one I'd choose, but then that's why I'm not a Captain of Industry.

"Another problem is the I/O contention at shutdown.  With the mad rush of programs trying to scribble data on the disk, you're lucky if you can write a couple sectors before your five seconds expires."

Even worse, what if Windows had to wait to terminate a process during shutdown because, for example, the process have pending IRPs that could not be finished in time because of the I/O contention?

If you don't know what I am talking about, see this:

http://blogs.msdn.com/oldnewthing/archive/2004/07/23/192531.aspx

@pete: from your description it seems that both sender and receiver are under your control, so why don't you use private message?

[People would avoid TaskDialogs because XP misdetects them. "A program that uses TaskDialogs behaves worse on XP than a program that uses MessageBox. I'll stick to MessageBox." (Of course, for the purpose of discussion, replace TaskDialog with some other UI design that works on XP.) -Raymond]

But XP can't "misdetect" them because they don't exist in XP.*  I'm not sure I'm understanding: if it is a UI design that works in XP, it was either there already (and so should have been handled) otherwise it was backported (and so the handling should have also been backported).  If it isn't backported, then it doesn't exist, and there's no need to worry.

Again, I'm only talking about MessageBox and its equivalents.  

*Nitpicker's corner: yes, they can be emulated, but that's your own problem, and yes, there is a wrapper that will show a TaskDialog on Vista and a MessageBox on XP, but the entire assumption is that the MessageBox was handled.  

Also, what about if the network goes away during shutdown, which is common on wireless networks, and to terminate the process Windows have to wait for the network to time out?

@Mark:  they did redesign the shutdown UX in Vista, so I think your problem is more of an XP-specific issue.  If I recall, in Vista if it detects there are apps blocking shutdown, it will show you a list of blocking apps and gives the user a chance to abort the shutdown (within a 10-second timeout or similar).  I think Vista even allows an app to specify a string describing why it doesn't want to quit (but the app of course has to use the new API to specify the string).

Anyway, it's probably a better idea to train the user to save their work frequently if they're using an app that doesn't have an auto-save feature.  After all, the machine can always unexpectedly blue-screen or losses power.

pete: The .NET Process object has a CloseWindow method that closes the main window of the program, which in many GUI programs will cause the program to quit, unless it's a system tray program, (you can't really signal those to quit anyway since they may have no window to send messages to, unless they specifically provide for interprocess communication).

I don't know if there's a specific WinAPI function to figure out the main window for a program, but I bet .NET simply assumes the first window the process created is the main one, which would be a reasonable assumption that would work for most cases.

At any rate just keep in mind it's going to be impossible to get 100% compatibility because of the variety of programs and program behaviors out there.

I don't like how some programs, like Explorer, wait until they close (in Explorer's case, you have to log out) before saving settings.  Since I rarely reboot or shutdown unless a BSoD occurs, this means I usually end up reapplying a setting change I applied last session.  So in my own programs I simply write settings to disk once they are changed within the program.  I have a .NET class which has a standard Collection and allows you to index settings, and writes a new settings file out to disk whenever one is changed (as well as a "I'm about to set lots of settings, don't write yet" BeginUpdate and EndUpdate methods).

I have to agree with Raymond on Mark's suggestion.  Lots of programs use custom dialogs and so basically you'd be trying to detect if a process opens a window after you try closing a different window.  This is so generic it's going to cause problems.  And who says the program won't hang while showing this new dialog?  Then you have a real problem.  I believe Windows' current handling is correct... a program should not be showing a dialog on shutdown since Windows IS going to obscure it.  Of course then you can't prompt the user to save their document.  There are workarounds to consider including automatic persistence between application sessions.

@pingpong:

Well, firstly, I don't have total control over the sender, because it's an installer script with limited message sending capabilities. But that's not the end of the world, because I am effectively doing as you suggest anyway. As RC mentions nearby, one cannot expect to get away with sending WM_CLOSE to arbitrary hidden windows, but we know it works reliably for mine, which makes this use of WM_CLOSE effectively private. The installer script is happy to send WM_CLOSE to arbitrary windows, so everything is working a practical level. And, if some other (foolhardy) app happens to send WM_CLOSE to my hidden window, that's OK too.

The reason I bring up this issue has less to do with solving any immediate practical problem I have and more to do with: [1] wondering why I should have had to spend any time thinking about this, and [2] mild concern that some future maintainer of the sender will conclude that all receivers are supposed to work as well as mine.

@Dan:

Remember The Old New Thing is "not actually a .NET blog". :-) I'm using Win32.

As well, since you mention it, it happens the app in question's only visible human interface is a task bar icon, though it also needs a window so that the system can send it various sorts of hardware and registry-related notification messages. Since I don't need the window for anything else, I hide it, and since the window hangs around for the lifetime of the app anyway, I just tell the installer to send it WM_CLOSE. Works fine.

But in addition to the concerns I mentioned above, let's suppose I didn't need to have a window for any other reason... then there'd be no standard way for the installer to quit my app, right? That's what I'm talking about.

I realize most people don't care about this kind of stuff, but I write lots of dinky little utility apps.

"Suppose that the new recommendation in the next version of Windows is "Don't use MessageBox, use X's" where "X" is something that works on XP, but which almost nobody uses (e.g. a custom dialog box). Should the "X detection at shutdown" code be backported to XP? -Raymond"

Well, developers' use of custom dialogs would require Windows to read the developer's mind anyway (unless it was some kind of specially flagged custom dialog) - but in any case that's changing the rules after the hypothetical XP's game is over.  In any case I don't think it was expected that this was supposed to cover 100% of cases, just the most common ones (i.e. MessageBox/TaskDialog).  If no one was using the theoretical construct before, the rate of introduction of use of the new feature vs. the rate of attrition of older OSes should make it a rare enough case as to not matter.  In any case, generalizing to modal dialog boxes would probably cover 99% of past and future cases and if the developer is doing something funky, the onus should be back on them with WM_QUERYENDSESSION.

"@Mark:  they did redesign the shutdown UX in Vista, so I think your problem is more of an XP-specific issue.  If I recall, in Vista if it detects there are apps blocking shutdown, it will show you a list of blocking apps and gives the user a chance to abort the shutdown (within a 10-second timeout or similar).  I think Vista even allows an app to specify a string describing why it doesn't want to quit (but the app of course has to use the new API to specify the string)."

Right, but the hypothetical detection could be used in concert with this UI.  Remember the original complaint was the "End program" message box being on top of the Save/Don't save dialog.  Vista's black replacement shutdown screen doesn't change the principles here.  All that's being said here is it would be nice for these constructs to not cover Save dialogs.

have never done anything about this.. MFC has magically handled it for me without me ever having to learn about this :P

The developers, including MS, need to remember to do the same state save on WM_(QUERY)ENDSESSION, as they do on WM_CLOSE. So far the offenders are REGEDIT (doesn't remember the last key, if session was shut down, as opposed to the app closed), and Visual Studio - doesn't save the last workspace.

"All that windows needs to do is pop up the kill it? dialog not in the center."

Forget the impossible question of determing whether an app is asking a question. Just determine which window has the focus and if the Kill-It dialog completely covers it up (easy problem), move the KillIt dialog slightly, so the *user* can determine that the program is asking a question (hard problem).

This doesn't help existing apps, but what about the idea of having the return value from WM_(QUERY)ENDSESSION encode "Uh, wait a second, I'm asking the user to save data.", which also at least somewhat validates that the app is running "correctly". Or creating a new function to indicate that, since who knows what existing apps might be returning for those messages now, regardless of what the docs say.

I'm not 100% sure what the right response is for Windows, though. Perhaps to extend the timeout, and make sure the window's dialogs appear to the user (or at least not covering them up with "kill this app" messages :-), and then perhaps sending those apps another message later (WM_REALLYENDSESSION? :-) telling the application it's got one last chance to do something before it's killed.

Complicated... yeah, I suppose I'm complicating the ENDSESSION handling in order to deal with the problem of apps not handling ENDSESSION correctly, but in this case it seems like a backwards compatible and useful to the user complication.

(and, yes, if there were a system power state problem that made the situation more urgent, sending the new message right away, before the extended timeout, would be a reasonable reaction... what else are you going to do?).

> Raises the topic of what I consider to be one of the worst dialogs in windows. When shutting down if an app pops up a 'save ur work?' dialog the windows pops up a 'this app is dead - kill it?' dialog after a short time.

It's already been addressed, but I love how many programmers are ignorant of things like the halting problem.

> This weekend I was cleaning gigabytes out of my temp folder, wondering how all this junk gets left behind.

Windows doesn't clean its temp folder? It probably should.

Perhaps there should be an API for specifying blocks of data to the OS that should be saved were the session to end abruptly.

Sounds like a database thing. Seriously, that's a lot of overhead.

@Pete:

The real question is why you are telling something to close from an installer?  Why don't you prompt the user to do it for you or provide the contract to close to the actual application?

Installers shouldn't be asking other applications to close - look at the Windows Installer pattern for reasons why this is.  MSI 4.0 exposes new functionality to support the Restart Manager.  Support that from here on out.

The issue is that you assume there's a generic way to close down an application when there's not.

"Um, how can Windows act on the return value from a function that hasn't yet returned? -Raymond"

I think the idea was for WM_QUERYENDSESSION to return a new value meaning "I'll have to ask the user first" and then have the app call a new API later on saying "yeah, ok, reboot", or "the user doesn't want to reboot".

But I don't think that's a workable solution, since apps have proved time and time again that they can't be trusted.  (Someone somewhere is going to write an app that always responds "don't reboot!" without actually asking the user.)

@Bryan: It's reasonable to have an installer request an application to close, provided that (a) it's the same application that the installer is trying to install and (b) it's done cooperatively, so the app is allowed to say "no, because the user still has a dialog box open".  Arbitrarily killing other processes is definitely a no-no, though.

This is a terrible problem.  Too many programs are guilty of not saving settings when the session ends.

It's best practice to save settings periodically, not defer that task until the program is closed.  Not only will this prevent setting changes from being lost when the session ends, but also if there is a system crash or power outage.

PingBack from http://blogs.msdn.com/michen/archive/2008/04/04/Application-termination-when-user-logs-off.aspx

I think best is to save app state on WM_QUERYENDSESSION, and there also you can without problems ask the user to save their documents.

This is the time to clean up temp files too.

So on WM_ENDSESSION the app has little if nothing to do besides quickly terminate.

@Bryan:

I'm glad we agree there isn't a generic way to quit an application programmatically, but you seem to have missed my point, which is: I want one.

Why? Well, in this particular case, I have an installer which wants to upgrade my app, and Windows won't let me do anything interesting to the app's file if the app is running.

I must confess I don't know all that much about MSI and Restart Manager. I am, after all, not the installer guy. But I can tell you for certain that restarting sucks. We bend over backwards to avoid forcing the user to restart.

In any case, Mac OS has supported app A telling app B to quit for about 16 years now. There's nothing particularly dangerous about it. App B is free to refuse.

"Um, how can Windows act on the return value from a function that hasn't yet returned? -Raymond"

So turn the method around. Have applications that ask the user a question call the new API function "IAmAskingTheUser()" before displaying the dialog. Then the system knows that the application is actually responding to WM_QUERYENDSESSION, not hanging.

The method is backward compatible - existing applications that don't call IAmAskingTheUser() behave no worse than currently: the system thinks they're hanging.

New programs that use the method get progressive enhancement.

Although I also like the earlier suggestion of automatically detecting this. I think this could be accomplished simply by marking the program as "waiting for the user" if it calls GetMessage or one of its equivalents. Thus, you catch every message loop the program enters, be they from MessageBox, TaskDialogs or feature XYZ in Windows.Next. It wouldn't catch for example reads on standard input, but that's probably fine.

"And of course, you can't close a disabled window."

I have to enable all (child-) windows I want to close....?

It won't be possible to process WM_CLOSE (as in this context)?

No way - I mean it's possible, but I agree it's definitely wrong.

(Someone somewhere is going to write an app that always responds "don't reboot!" without actually asking the user.)

Incidentally, that's already a problem when apps swallow the WM_QUERYENDSESSION message (usually by not passing messages off to DefWindowProc (http://blogs.msdn.com/oldnewthing/archive/2006/04/25/583093.aspx)

>Why? Well, in this particular case, I

>have an installer which wants to upgrade

>my app, and Windows won't let me do

>anything interesting to the app's file

>if the app is running.

Strawman!  Btw "Windows" is not the problem. Would you be replacing the files that your using while it's running?  In any case, you don't need something generic for Your installer to quit Your app.  

It's Your app.  You do a find window and send WM_CLOSE to it, that's all.  You know how to do it.  Quittting your own app from an installer is not a problem

"It's Your app.  You do a find window and send WM_CLOSE to it, that's all.  You know how to do it.  Quittting your own app from an installer is not a problem"

Especially if it's running in a different session.

@Ulric:

Like I said, this is not a practical problem for this particular case. I already told the installer to send WM_CLOSE to a hidden window and the app interprets that to mean it should quit. It works. Having done that, I still have some concerns about the fact that every app which needs to be quit programmatically must come up with its own protocol. Details above.

But, to respond to your exclamation, someone asked why I want the installer to quit my app. I responded that the installer can't replace the app's file while the app is running. I'm not sure how or why that's a straw man. It's merely background information. It wasn't intended as an argument for or against anything, and I'm not sure why you took it that way.

Really, I jumped in here to ask if anyone knew a generic message app A could send to app B to tell app B to quit. It seems odd to me that such a message does not exist. I'm not sure why that makes people so argumentative. Oh, wait; I forgot; it's the internet; sorry; my bad. I am starting to feel like RC must feel every day.

Before the mystery of “Why the Visual Studio debugger occasionally locks up the entire Windows GUI” was solved (http://www.virtualdub.org/blog/pivot/entry.php?id=118) I would keep and instance notepad with a dirty document running.  

Since logging off was the only command that worked I could use it to kill VisualStudio but prevent having to completely log off and back on again by selecting Cancel when notepad prompted to save changes.   This worked well as a way to abort the log off once it was started.

@reader:

"Anyway, it's probably a better idea to train the user to save their work frequently if they're using an app that doesn't have an auto-save feature."

Auto-save can be a battery killer on a laptop if it has to spin-up an otherwise idle drive.  Power management isn't a flashy "back of the box" feature, but it's still a tax that we should try to pay.

"I jumped in here to ask if anyone knew a generic message app A could send to app B to tell app B to quit. It seems odd to me that such a message does not exist."

Remember, Windows is not Mac OS. Windows does not have the same concept of an "application" like Mac OS does.

In Windows, windows are the target of all interactions. You can't send a "quit application" to a window, because you don't know what "application" that window may belong to.

@Dean:

Of course.

You write that, though, as if it's a sacred axiom, as if there's some value to its ideological purity, as if it's something more than a general organizing principal or -- heavens -- a mere implementation detail.

As well, technically speaking, it isn't quite true; functions such as GetWindowThreadProcessId and GetModuleFileNameEx do exist, so you CAN tell which app owns a window, though that doesn't give you a single target for a message.

Ultimately, though, all I was looking for was a message which worked like sort of a hybrid of WM_QUERYENDSESSION and WM_ENDSESSION explicitly documented for use by applications. I can accept that it doesn't exist, and all I really expect after that is to be able to say it seems funny to me that it doesn't.

[And what if the program calls IAmAskingTheUser and then hangs inside its dialog? (E.g., it wants to show an icon in the dialog, and the icon resides on a server that is down.) And just because a program is calling GetMessage doesn't mean that it's waiting for the user. It might be waiting for a remoted COM object. This happens more often than you think. We're back to the question, "Are false positives and false negatives acceptable?" -Raymond]

OS X solves this problem.  Apps are considered to have "hung" when they stop processing events.  Apps displaying modal dialogs still respond to events, so the OS knows they haven't crashed.

This whole issue is trivially solved.  Only MS's steadfast devotion to keeping old APIs alive stops them from cleaning up this part of the OS.

A thread waiting for a slow COM object is the same case as the user ignoring a save query.  The thread tells the OS it needs more time, but at some point the OS may have to issue an ultimatum.

I don't see how giving the OS and user more information breaks old programs.

Perfect timing to bring this point to my attention. A very random and quirky data loss problem was fixed today.

From my perspective, all non-trivial false negatives are acceptable because sometimes an OS vendor should let customers demand fixes from developers. This is the approach Mac OS has always taken. Windows can't do this (now) because there are plenty of buggy apps out there which are part of workflows which rely on apps being forcibly quit and will never be fixed because nobody has the source. It was a mistake for Windows to ever start forcibly quitting apps on logout, but the mistake's well and truly made now and there's no use in agonizing over it.

Just make the killing dialog transparent