
	`About \| Forum \| Gallery \| News \| Order the XPT \| Products \| Rants \| Security \| Services \| Workshop`

Home » Services » Courses

Windows Architecture & The Windows Programming Model

Windows Programming

Developing Windows applications demands a good understanding of the concept of event-driven programming, the use of graphical data, the pre-defined Windows controls, and last but not least, a good sense of taste in designing an application's user interface - regardless of the development method used.

Traditional programming is sequential: the program itself determines the control flow and calls the operating system whenever it wants to, and that's the contact they have with one another, the application and the system. It's a one-way street. Event driven programming turns everything on its head: more often than not it's the operating system calling the application, not the other way around. If the program user clicks a mouse button, for example, the operating system sends a message to the program window procedure informing it of this event. Each and every window has a message queue and each and every window has an associated window procedure to take care of incoming messages. Within each procedure the incoming messages are filtered, analysed, and handled if found to be of interest. Irrelevant messages are ignored and afforded a default response by the operating system. Following is a short description of some of the more common Windows messages.

Message	General Description
WM_ACTIVATE	A window is being activated or de-activated.
WM_CHAR	A keyboard character has been depressed and released. Normally a 'message loop' will contain code to transform `WM_KEYDOWN` and `WM_KEYUP` messages into `WM_CHAR` messages for the application.
WM_CLOSE	The user wants to close the application window.
WM_COMMAND	The user selected something from the window menu, or a 'child window' is 'calling home' (in Windows, everything - every button, scroll bar, edit field - is a window).
WM_CREATE	The first message ever sent to a window, sent directly by the system. Returning -1 indicates the window should not be created.
WM_DESTROY	The only message even the most skeletal of application frameworks must catch, sent when the application window is removed from the screen but before the application stops running, and the application must respond by calling `PostQuitMessage` to stop it.
WM_ENDSESSION	Sent after `WM_QUERYENDSESSION`. The system might be going down, depending on whether any running application 'objected' when receiving the previous message.
WM_HSCROLL	Something happened to a horizontal scroll bar.
WM_INITDIALOG	The first message caught by a standard dialog procedure, sent when a dialog is about to be displayed.
WM_KEYDOWN	A keyboard key has been depressed.
WM_KEYUP	A keyboard key has been released.
WM_LBUTTONDBLCLK	Double click of the 'primary' mouse button.
WM_LBUTTONDOWN	The 'primary' mouse button is down.
WM_LBUTTONUP	The 'primary' mouse button is up.
WM_MOUSEMOVE	The mouse has moved within the 'client area'.
WM_NCMOUSEMOVE	The mouse has moved within the 'non-client area'. All 'normal' mouse messages have 'non-client' counterparts.
WM_NCPAINT	The 'non-client' area needs painting. Afforded a rather non-trivial response by the default handler.
WM_NOTIFY	A 'new look and feel' common control is 'calling home'.
WM_PAINT	Part of the window's 'client area' needs 'painting' (updating).
WM_QUERYENDSESSION	The user wants to end the Windows session. The window procedure returns a value indicating whether it 'approves' or not.
WM_RBUTTONDBLCLK	Double click of the 'secondary' mouse button.
WM_RBUTTONDOWN	The 'secondary' mouse button is down.
WM_RBUTTONUP	The 'secondary' mouse button is up.
WM_SETFOCUS	Your window is getting keyboard focus.
WM_SIZE	The window has been re-sized.
WM_SYSCOMMAND	The user selected something from the application System menu, such as 'Restore', 'Move', 'Size', or 'Close'.
WM_TIMER	A 'click' of a timer created by a call to `SetTimer`.
WM_VSCROLL	Something happened to a vertical scroll bar.

The complexity of this system grows with each new Windows version - so once again, remember: it's not knowing it all that counts, but instead knowing what counts.

Windows was not originally a true multitasking system, in fact the term 'co-operative multitasking' was invented to describe it (and MacOS). Meaning Windows appeared to be a multitasking system when in fact it was not. It relied on the 'good social behaviour' of its applications to run without a hitch. Applications which received more messages than others got more CPU time. Moreover, if a Windows application entered a wild loop the whole system suffered. The classical

for (i = 0; i < 10; )
    ;

Where the incremental operation is left out at the end could bring the whole glorious house of 'old' Windows crashing down. It was only by going back to the operating system after having processed a message that an application relinquished control of the CPU and Windows could get its hands on it again.

Today, with the advent of Windows 95 and Windows NT, this danger is a thing of the past. What remains, however, is the classical programming model - wait for a message, dispatch it, associate all windows with corresponding procedures that are called in one way or another by the operating system. Today's Windows cannot lock the interface as 'old' Windows could, looking for a new message does not return control to the operating system - the operating system is always in control. Asking for a message does, however, clue the operating system in to the fact that the calling thread is idle.

↓ Graphics