Chapter 26 -- Window Messaging

[Previous] [Next]

Chapter 26

This chapter describes how the Microsoft Windows messaging system works for applications that present a graphical user interface. When designing the windowing system used by Windows 2000 and Windows 98, Microsoft had two major goals in mind:

• Keep as much backward compatibility with 16-bit Windows as possible, making it easy for developers to port their existing 16-bit Windows applications.
• Make the windowing system robust so that one thread cannot adversely affect other threads in the system.

Unfortunately, these goals are in direct conflict with one another. In 16-bit Windows, sending a message to a window is always performed synchronously: the sender cannot continue running until the window receiving the message has completely processed it. This is usually a desired featured. However, if the window receiving the message takes a long time to process the message or if it hangs, the sender can no longer execute. This means that the system is not robust.

This conflict made for some interesting challenges for Microsoft's design team. Their solution is not perfect, but it is an excellent compromise between the two aforementioned goals. If you keep these goals in mind as you read this chapter, you'll understand why Microsoft made the design choices it did.

Let's start off with some ground rules. Windows allows a single process to create up to 10,000 different types of User objects: icons, cursors, window classes, menus, accelerator tables, and more. When a thread calls a function that creates one of these objects, the object is owned by the thread's process. So, if the process terminates without a thread explicitly destroying the object, the operating system will automatically destroy the object. However, two User objects—windows and hooks—are owned by the thread that creates the window or installs the hook. So, if a thread creates a window or installs a hook and then that thread terminates, the operating system automatically destroys the window or uninstalls the hook.

This concept of thread ownership has an important impact on windows: the thread that creates a window must be the thread that handles all messages for the window. To make this concept more concrete, imagine a thread that creates a window and then terminates. In this case, the window will not receive a WM_DESTROY or WM_NCDESTROY message because the thread has terminated and cannot possibly be used to allow the window to receive and process these messages.

This also means that every thread that creates at least one window is assigned a message queue by the system. This queue is used for window message dispatching. In order for the window to receive these messages, the thread must have its very own message loop. In this chapter, we examine each thread's message queue. In particular, we'll see how messages are placed in this queue and how a thread extracts messages from this queue and processes them.