1. What does an application instance mean?
2. When the application retrieves a message from the queue, what changes does it make to the message before it dispatches it to Windows again?

1. What does an application instance mean?

When an application starts, Windows gives it a unique number. In C++ this instance is stored in the HINSTANCE data type. This "instance" (which is also sometimes referred to as a "handle") can then be passed as a parameter to Windows API functions. For example if your application calls the function CreateWindow then you pass in the handle to your application so that Windows knows which application the window will belong to.

2. Why would message go back to Windows? It does not. Application processes the message and then life of the message ends.

2. If we are talking about a window procedure, then all messages go through that procedure and an application can either choose to process a message or to ignore it and pass it to the next procedure in the list (and may modify the message as well). The final window procedure is owned by Windows by default, so any message that isn't processed eventually gets passed to it for default processing (drawing the window for example). At least that's how I understand it.

Pure Win32 API does not pass messages "down the road". MFC, probably does. Once you register a window class and message reaches the WndProc declared in that WNDCLASS structure - you can pass message to DefWindowProc() or to ignore it. However, some messages are processed by DefWindowProc() may be rerouted to system (WM_MOUSEWHEEL as an example) - that is possible.

Sure, but I was also considering the situation where a window is subclassed. If it is, then the message is passed on to the next handlers via CallWindowProc and the last user-defined procedure "on the road" passes it to DefWindowProc and the message is then handled by Windows.

I am very confused. I thought the process was as such:
1. The application retrieves a message from the message queue.
2. It translates, then dispatches the message back to Windows.
3. Windows passes the message through the Windows Procedure to determine what it should do with the message. If the message is not contained within the switch statement, it is passed in DefWndProc.

My question is, what really happens at Step 2?

You've understood it correctly. The point that I was trying to make was that there may be more than one window procedure handling the messages of a single window. In that case it is called subclassing and the procedures are called in a list where one calls the other. Sorry if it confused you..

Anyway, after successfully creating a window, there is usually a loop like this:

   MSG msg;
   while (GetMessage(&msg, NULL, 0, 0) > 0) {
     TranslateMessage(&msg);
     DispatchMessage(&msg);
   }

Step 1 is done by GetMessage, it retrieves a message from the queue into the msg structure.

In step 2 TranslateMessage deals with simplifying keyboard input management. For example, normally when you press a key you get a "key down" and a "key up" message. TranslateMessage sees these messages and produces a new message with simply the key that was pressed.

And as you said, DispatchMessage sends messages to the window procedure associated with the window.

Don't hesitate to ask if something still isn't clear! :)

Thanks for the clarification. I've also read that when the message is retrieved from the message queue, the application does some additional preprocessing to it before it is dispatched to Windows -- for example, "the application might call different functions in Windows to process specific kinds of messages."

Are there any specific examples of this?

That's good, but sub-classing code is the responsibility of the programmer. If programmer will not pass the message to the original (before sub-classing) procedure - then message simply swallowed by application and system will not do anything automatically.

If I understand this correctly, you have 3 WindowProc during subclassing: the subclassed WindowProc (written by programmer), the original WindowProc (written by programmer) and the default WindowProc (default behavior handled by OS). Is that correct?

That's right, though you can have even more procedures. When you want to subclass a window, you first get and save the pointer to the procedure associated with the window using GetWindowLong. This pointer is then replaced with the pointer to your own procedure using SetWindowLong. Your procedure will then create a link to the previous procedure by passing the saved pointer to CallWindowProc. When subclassing is no longer needed, the old pointer is set back as the associated WindowProc. With this kind of system it's possible to define several procedures.

Also, if you subclass a system-defined class such as EDIT or BUTTON, then there might be only 2 procedures: the subclassed WindowProc and the default WindowProc.