http://bugs.winehq.org/show_bug.cgi?id=1918
------- Additional Comments From jbj@image.dk 2005-11-10 00:06 ------- There is a misunderstanding in Mike Hearns comment #4 (from 2004-01-02). The way this is supposed to work (in all known windows versions, even 16 bit) is:
1. PostMessage places WM_CLOSE in the queue, no special treatment
2. GetMessage/DispatchMessage passes WM_CLOSE to the WindowProc, no special treatment.
3. The WindowProc in the App does whatever it pleases, including deciding if it wants to call DefWindowProc or not. In the sample this happens to be a call to DestroyWindow, but anything goes. If WindowProc had contained code to pass the message on to DefWindowProc, DefWindowProc would have called DestroyWindow too, but DefWindowProc is not called in the sample. There is still no special treatment. Some applications RELY on the ability to refuse WM_CLOSE by simply doing nothing. For instance Notepad will invoke MessageBox (Save Yes/No/Cancel) and do nothing if the user clicks cancel.
4. DestroyWindow is supposed to SendMessage(WM_DESTROY) as one of its last actions, causing WindowProc to be invoked recursively to handle that message. I suspect the original bug was that this did not happen correctly.
5. The samples WindowProc happens to call PostQuitMessage from its WM_DESTROY case, but if the WindowProc is never called with WM_DESTROY due to a wine bug, this doesn't happen.
6. If PostQuitMessage was actually called, the WM_QUIT message will end the message loop once it trickles to the head of the queue. But if PostQuitMessage was never called, this obviously won't happen.