Windows Architecture & The Windows Programming Model

Graphics

GDI32 takes care of all forms of graphical output. The GDI programming interface is used regardless of whether the target device is a screen, a printer, a bitmap, or whatever. The GDI module communicates with the target device, draws its own conclusions about the device's built in capabilities, and translates graphical operations into a language the device will understand.

Controls

Windows has a number of pre-defined window types: program windows, dialog boxes, and child windows. Further there are a number of pre-defined (by User) 'controls': edit controls (text boxes), push buttons, check boxes, radio buttons, menus, scroll bars, combo boxes - in themselves bona fide windows, each having a corresponding window procedure - we'll be getting into this tin of worms in good time. The Windows 95 and Windows NT 4.0 interfaces have added another 2-3 dozen controls which behave in a way not at all like their older brethren. Now we have built-in toolbars, status windows, property sheets, progress controls, MCI (Media Control Interface) windows, animation controls, list views, tree views, and more. While it is possible to create your own controls for your program's user interface, it is far better to stick to the pre-defined collection - that's what the average user is familiar with, and it's far more important during these first few arduous months to learn properly how to use what we've already got to work with.

In the next chapter we will start looking at a standard Windows application framework. This was hard enough work in the old days, when that one printf line for your first 'Hello, world' program became 63 instead. But nowadays all applications must have 'new look and feel' controls as well, so it will be even more difficult. Building a windows application framework means learning about how to register window classes, write your entry point function - no longer main but WinMain - write your window procedure and maintain a number of Windows resources. Windows is a message oriented operating system, so the bulk of your code will be in your window procedure where you respond to incoming messages about events.

Lab

1. Just how much messaging goes on in Windows is usually, for the uninitiated, something of a shock. Spy++ is an MSVC utility that spies on, among other things, the messages sent to application windows - and other windows, for that matter. Check out your development environment and locate and run Spy++. And use the 'Find Window' function and see how many windows you can find on your desktop.
2. Gone are the days when you blew the dust off your programmer's reference manual once or twice a year searching for some seldom-used function. Function documentation today must be on-line, functions are never 'seldom used', there's no way you'd make it otherwise. Acquaint yourself with your development environment's Help system - you'll be wearing it out in no time flat, so make sure you know how to use it effectively.

↓ A Windows Application Framework