Basic's in Windows Architecture :)

this thing is going to be very very boring , but certain things have to be explained before moving to FUN.
New Concepts:

Types of window
Windows Messages
The Window Procedure
The Window Class
The Message Queue & Message Loop
Dialog Boxes & Child Window Controls
Handles

This section is necessary before we go any further in order to understand the concepts surrounding windows and dialogboxes.
Types of Windows

Windows programming is Object-Oriented, the key objects being the windows themselves. There are various types of windows such as the main window of an application which may contain a title bar that shows the program's name, a menu, and perhaps a toolbar and scroll bar. Other types of window are the DialogBox, which may or may not have a title bar, and the very basic MessageBox. Push buttons, radio buttons, check boxes, list boxes, scroll bars, progress bars, and text-entry fields which are part of a main window are also types of windows called "child window controls." We will discuss dialog boxes and child window controls in more depth below.

There are 2 important areas to a standard window. The client area is the main part of a window where the application displays output, such as text or graphics. The title bar, menu bar, window menu, minimize and maximize buttons, sizing border, and scroll bars are referred to collectively as the window's nonclient area. The system manages most aspects of the nonclient area; the application manages the appearance and behaviour of its client area:

Posted Image

Windows Messages

Windows receive user input such as keyboard or mouse interaction in the form of "windows messages" from the operating system. A window also uses messages to communicate with other windows. For example, when the user drags the border of an app’s window to resize it, the OS handles all the messy code for allowing the window size to be changed, yet the app will respond by altering its display to fill the new window. How does the app know when the window has been resized? The OS sends the program’s window a message instructing the change. Another example of this is how a push-button window knows that it's being "clicked". In most Windows programs, the bulk of the program is dedicated to handling messages. A message consists of a MessageID beginning with letters indicating the type of the message (eg WM_) and two parameters (lParam and wParam) which (if necessary) contain additional information.

The Window Procedure

The OS sends messages to a program by calling a special function (the "window procedure" or WndProc) inside it and passing the message as a parameter. Functions writen by the programmer which the OS calls in this way are termed "callback procedures". Every window that a program creates has an associated window procedure which processes messages from the OS and other windows. All the real action occurs in the window procedure - almost everything a Windows program does is in response to a message to a window procedure. The window procedure determines what the window displays in its client area and how the window responds to user input. Windows calls WndProc when a window is created and destroyed. Your window procedure will receive messages that it does not need to process itself and in this case you must pass the message on to the Windows default message handler DefWindowProc for processing.

The Window Class

A window is always created based on a "window class". The window class defines the window procedure that processes messages to the window. The use of a window class allows multiple windows to be created based on the same class and hence use the same window procedure. For example, all button windows—including push buttons, check boxes, and radio buttons—are created based on the same window class. This window class is associated with a window procedure located in a system DLL that processes messages to all the button windows. Before you create an application window, you must register a window class by calling the RegisterClass function. The window class also defines the general characteristics of a window including icons and background colour.

When you create a window by calling the CreateWindow function, you specify more detailed information about the appearance of the window. For example we know all push buttons work the same way as they all use the same WndProc, but not all push buttons look the same. They may have different sizes, different locations on the screen, and different text strings. These characteristics are part of the window definition rather than the window class.

The child window controls mentioned above have 6 predefined classes: BUTTON, COMBOBOX, EDIT, LISTBOX, SCROLLBAR, and STATIC. These "common controls" are registered by calling the InitCommonControls function.

The Message Queue and Message Loop

When a Windows program begins execution the OS creates a "message queue" for the program. This message queue stores messages to all the windows a program might create. A Windows application includes a short chunk of code called the "message loop" which retrieves messages from the queue by calling the GetMessage function and dispatches them to the appropriate window procedure by calling DispatchMessage. Other messages are sent direct to the window procedure without being placed in the queue.

It is said that queued messages are "posted" to a message queue and that nonqueued messages are "sent" to the window procedure. Queued messages usually result from user input in the form of keystrokes, characters that result from keystrokes, mouse movement and mouse-button clicks but also include the repaint message to refresh the display (WM_PAINT) and the quit message (WM_QUIT). Nonqueued messages are everything else and often result from calling Windows functions. For example, when WinMain calls CreateWindow, Windows creates the window and in the process sends the window procedure a WM_CREATE message.

Dialog boxes and Child Window Controls

Dialog boxes are nothing more than normal windows which are designed to work with child window controls. They can be used as an input device to the main window of your application or as the main window itself. The size and layout of a dialog box and its controls are defined in a "dialog box template" resource script. This can be written manually but is far better set up using WinAsm's Visual Resource Editor.

When a program invokes a dialog box based on a template, Windows is responsible for creating the dialog box popup window and the child window controls, and for providing a window procedure to process dialog box messages, including all keyboard and mouse input. Since child window controls process their own mouse and keyboard messages and notify the parent window when their states have changed, this relieves the burden from programmers enormously. The code within Windows that does all this is sometimes referred to as the "dialog box manager."

Many of the messages processed by the dialog box manager are also passed to a callback procedure within your own program called a "dialog box procedure" or "dialog procedure." A dialog procedure is similar to a window procedure in that Windows sends messages to the procedure when it has information to give or tasks to carry out. Most dialog box procedures process the WM_INITDIALOG message and any WM_COMMAND messages sent by the controls, but process few if any other messages.

Unlike a window procedure, a dialog box procedure never calls the DefWindowProc function. Instead, it returns the value TRUE if it processes a message or FALSE if it does not. In other words, if a dialog procedure does not process a message, it must return FALSE to direct Windows to process the messages internally. The only exception to this rule is the WM_INITDIALOG message. The dialog box procedure must return TRUE to direct Windows to further process the WM_INITDIALOG message.

You can communicate with any child window control on a dialog box (via its unique control ID number) by using SendDlgItemMessage function. Win32.hlp lists the available messages but Windows also provides several control-specific API functions to get and set data quickly, eg GetDlgItemText, CheckDlgButton etc. These control-specific functions are provided for the programmer's convenience and to make the sourcecode more readable. Resort to SendDlgItemMessage only if no control-specific API calls are available.

The 2 Main Types of Dialog Box

modal - commonest, eg "About" box from help menu. The user cannot switch between the dialog box and another window in your program. The user must respond to the dialog box first. The user can, however, switch to another program. Created by calling DialogBoxParam which returns a value only after the dialog box is destroyed. If you include the DS_SYSMODAL style in the dialog box template, it will produce a system modal dialog which must be ended before the user can do anything else in Windows.

modeless - eg text "find" box in word processor. Allow the user to switch between the dialog box and the window that created it as well as any other programs. Created by calling CreateDialogParam which returns immediately with the window handle of the dialog box.

There are several other important differences:

1. modeless dialog boxes usually include a caption bar and a system menu box to allow the user to move the dialog box to another area of the display using either the mouse or the keyboard. You don't need this with a modal dialog box because the user can't do anything in the underlying window anyway.

2. If you neither include the WS_VISIBLE style nor call ShowWindow, a modeless dialog box will not be displayed at all.

3. Unlike messages to modal dialog boxes and message boxes, messages to modeless dialog boxes come through your program's message queue which must be altered to pass these messages to the dialog box window procedure.

Common Dialog Boxes

Windows has prepared predefined "common" dialog boxes for use by your applications including file, print, colour, font, and search dialog boxes. They exist to provide a standardised user interface and reside in comdlg32.dll so in order to use them you have to link to comdlg32.lib. You create these dialog boxes by calling appropriate functions in the common dialog library. For the "open file" dialog, it is GetOpenFileName, for the "save as" dialog it is GetSaveFileName, for the "print" dialog it is PrintDlg and so on. Each one of these functions takes a pointer to a structure as its parameter. They are listed in Win32.hlp.

WinMain, Handles and Instances

The EntryPoint to a Windows program is the function WinMain, which is called by the OS in order to begin execution after the program has been loaded from disk into memory by the Windows loader. In C/C++ programs, the label “WinMain” must be used but in assembler any label can be used. When an executable is mapped into memory by the windows loader, the in-memory version is known as a module. In 32bit Windows the starting address in memory (linear address) where file mapping begins equals the module handle.

A handle is simply a 32bit (DWORD-sized) number that the OS uses to uniquely identify every object it creates such as a window or pushbutton. You obtain the handle from Windows and then use the handle in other functions. The module handle identifies the program. The module handle is also known as the "instance handle" which is the first parameter taken by the WinMain function and is required as an argument to other Windows functions.

In early versions of Windows, when you ran multiple instances of the same program, all instances of the application shared code and read-only memory. A program could determine if previous instances of itself were running and then skip certain chores and move data from the previous instance into its own data area. In the 32-bit versions of Windows, this concept has been abandoned. The “previous instance handle” has remained the second parameter to WinMain but is now always NULL or 0.

Easy GUI Apps Using Dialog Boxes

Dialog boxes may be used as an input device for the main window of your app or the main window itself. This is achieved by calling DialogBoxParam to create a modal dialog box without a parent window. This approach simplifies program design considerably by using a dialog procedure instead of a window procedure and makes a message loop unnecessary since the messages are sent directly to the dialog procedure. The dialog box can be created based on a resource script made in a visual editor using child window controls which perform most of their own message processing. You don't even have to register a window class. We will use this approach for the examples in this tutorial.

At last the tutorial is over , Lets go to the fun parts now ^^