Inside a Windows Application

If you're new to development on the Windows system, writing applications in the .NET Framework may keep you from a full appreciation of what really happens inside a Windows application, and from being involuntarily committed to an asylum. That's because the internals of Windows application are no fun.

Windows was originally developed as an application running within MS-DOS, and this had a major impact on the design of Windows and of any applications running within its pseudo-operation-system environment. The latest releases of Windows are true operating systems, no longer dependent on MS-DOS. But the programming methodology was left unchanged for backward compatibility. Applications written in Visual Basic for .NET still use this Windows 1.0 technology internally, but it is mostly hidden by the many well-designed classes of the Windows Forms package.

Everything Is a Window

Rumors abound about why Microsoft attached the name "Windows" to its flagship product. Some say it represented the "Windows of Usability and Opportunity" that users would gain by using the enhanced Graphical User Interface. Some believe it represents the building cavity through which Microsoft executives promised to toss several key developers and managers if the product bombed. But the name actually refers to the different elements that appear on-screen when using Windows and its included applications. In short, everything you see on the screen is either a window, or appears within a window: all form, all controls, all scroll bars, and all display elements. Figure 7-1 points out some of the windows within a typical Microsoft Windows 2.0 display.

Figure 7-1. Some of the many windows of Windows 2.0

Every main application window was clearly a "window," as were all push buttons, text entry fields, checkbox and radio selection buttons, list boxes, and "combo" boxes (with a separate window for the "drop-down" portion). Static text and graphic images were drawn on a window's surface, and did not embody windows by themselves. But certainly there could be hundreds of windows on display at any one time.

Although the original developers on the Windows project team suffered from a deplorable lack of originality in the area of feature naming, Microsoft compensated for this somewhat with its release of Visual Basic. While everything was still a window internally, Microsoft divided the public world of windows into two hemispheres: forms and controls. There were always some internal differences between these two types of windows, and the new names did a lot to bring normalcy to the Windows application development situation. Microsoft elected to keep these useful monikers when it implemented the Windows Forms package.

Messages and the Message Pump

When you interact with Windows, it's pretty easy for you (as a human) to detect the different forms and controls on the screen. The image of Windows 2.0 I showed you in Figure 7-1 looks like a typical Windows screen, with its ability to interact with the keyboard and mouse, but it isn't. Go ahead; try to tap Figure 7-1 with your finger. You can tap all day long, but except for putting a hole in the page and not being able to get your money back on the book, nothing else will happen. But while you're tapping, you could shout out, "I just tapped on the 'OK' button," or "I just tapped on the '4' button of the 'Calculator' window."

This is what Microsoft Windows does for you. Windows keeps a list of all windows displayed on the screen, how they overlap and obscure each other, and which application each window belongs to. (Some applications are broken into multiple "threads" that all run at the same time. In such programs, Windows keeps track of all windows on a per-thread basis, not just on a per-application basis.) Each user input action (like mouse clicks and key presses) gets placed in the system message queue by the related device driver. As you click on the screen with your mouse, Windows extracts the system message from this queue, determines where you clicked, tries to figure out which window the mouse-click occurred on, and then informs that window's application about the mouse click by adding a message to the application's message queue. It does the same thing for keyboard input and other actions that a window might need to know about.

To function within the Windows environment, your application (or a specific thread within your application) includes a message pump, a block of code that monitors the message queue. Each incoming message includes the ID number of the intended window. The code extracts the message from the queue, and routes it to the window procedure (also called a WndProc) of the appropriate window for final processing. In the C language, this message pump looks somewhat like this.

while (!done) {    /* ----- Extract and examine the next message. */    MSG msg;    if (GetMessage(&msg, NULL, 0, 0))    {       /* ----- WM_QUIT means it's time to exit the program. */       if (msg.message == WM_QUIT)          done = true;       /* ----- Send the message to the right window. */       TranslateMessage(&msg);       DispatchMessage(&msg);    } } 

I know, I know. It makes you glad that you write in Visual Basic.

So, each application (actually, each thread within an application) has one message pump, but multiple window procedures. The message pump exists to route incoming messages to the correct window procedure.

Window Procedures

Just as the message pump dispatches messages to distinct window procedures, the WndProc routine directs processing to individual code blocks or procedures based on the type of incoming message. Here's a general logic outline (pseudocode) that shows the structure of a typical window procedure:

If (message type is a mouse click)    Do mouse-click related code Else If (message type is a key press)    Do key-press related code Else If (message type is a window resize)   Do window-resizing-related code Else... 

(The pseudocode uses successive If statements, but an actual window procedure would more commonly use a Select Case type of statement to process the incoming message.) So the window procedure is like a vending machine. If the customer pushes the cola button, do the processing that returns a can of cola. If the customer presses the chewing gum button, do the processing that returns chewing gum. If the customer presses the coin return button, keep the money.

So, for each type of message (at least those that the program wants to handle), there is some related code that gets processed when a message arrives. Boy, that really sounds familiar, but I just can't seem to recall what . . . events! This sounds just like events in Visual Basic. And so it does. Even way back in Visual Basic 1.0, all generated applications included a message pump and WndProc procedures for each window. The primary task of these WndProc procedures was to call the code in your Visual Basic event handlers.