Sorry if this is a repost or if it is covered in one of the episodes, couldn't figure out how to search and I'm only up to Push Buffer Rendering.
In writing the platform code for my own project, it occurred to me that the call to DispatchMessage may not even be necessary. Dispatch message seems to be designed for "dispatching" messages to their respective windows within an application. Since we only have the one window, we should be able to side step the call and process the messages outside of the window procedure in the same way as the keyboard input. This would allow us to remove the window procedure completely and allow us to get closer to the functional-ish style of program Casey describes when the keyboard input handling is originally pulled out. This should involve setting the window classes window procedure as DefWindowProc or, whatever its called, if I'm not mistaken.
Is this accurate?
EDIT: It occurs to me now that the meat of this isn't really whether or not DispatchMessage is called. It is more that we don't need a custom window procedure unless we act on unqueued messages. I don't have the experience to know whether or not that's something that happens often, but I presume its fairly likely and that its best to keep a custom window procedure. I guess that makes this post somewhat redundant, but typing it all out helped me think through the problem, and reading it might help someone else.
I think there are cases when Windows calls window procedure directly without adding message to the message queue. This may limit your options unless you don't care about those specific messages.
You cannot process only the message in the queue, because Windows sends (many!) of the message types directly to your window, unfortunately. Oh what a wonderful world it would be if they didn't :) But sadly, you must have a window procedure for gathering many of the messages, so usually it is just easier to use DispatchMessage() so you do not have to have _two_ places messages are handled, and try to figure out which ones go where (and when).
Yeah that's kind of what I realised, but expressed poorly, when I made the edit and talked about unqueued messages. Thanks for confirming that there are in fact a lot of "unqueued" messages.
I did the test at one point to see which of the messages I cared about (eg., game-relevant messages) went to the loop and which went to the window, and unfortunately there were definitely important ones that went to the window. I didn't bother to keep track, since all I needed to remember was "you have to have a WndProc", but I do seem to recall the message selection being very surprising, too... like, it wasn't necessarily messages that I felt had any real reason for being dispatched directly to the window, but I guess it's just the crazy disaster that is user32.dll at this point :/
Even if you have only one window, the WindowProc and DispatchMessage is needed. What happens if you call SendMessage from same thread where is window created? SendMessage waits until message is processed, it doesn't return until your code finishes processing message. So if you do only GetMessage/PeekMessage and don't use WindowProc/DispatchMessage then your message processing loop would never be able to process message sent by SendMessage. Only WindowProc can receive this kind of message, process it and return result back to SendMessage.
Basically SendMessage calls WindowProc of window if you are calling it from same thread. It uses message queue only if you are on different thread than window was created.
Of course HandmadeHero doesn't use SendMessage explicitly, but who knows what Windows API does internally. What if SetWindowLongPtr (which HH uses) or other functions (GL? D3D?) decides to use SendMessage to communicate with window?