Windows and Win32 Programming
The differences between GUI and command line architecture.
Jul 28, 2006
The main difference between Windows GUI programming and command line programming is that Windows itself is in control, and not the programmer. Of course, those who are familiar with command line programming can still write applications for the Windows command line (DOS box), but the advantages offered by the Windows GUI far outweigh the learning curve involved.
As an example : consider creating a simple text editor for DOS (or your favourite command line interface). The software has to handle text editing, cursor movement, menu interaction, and display any dialog boxes that might be required.
This might take thousands of lines of code; putting aside, for the moment, file handling, printing, and so on. The reader might like to take a minute to imagine everything that has to go into, say, the basic editing function. That is, allowing the user to type a letter, have it appear on the screen in the correct position, allow it to be deleted, and allow the user free movement of the cursor.
Windows programming can achieve all of this in a program with less than 100 lines of code. Of those 100 lines, only a handful (about 5) lines have anything to do with text editing. All the rest is automatic - Windows provides an Edit Control with all the logic inside for text editing.
This is made possible by having a class hierarchy that allows Windows programmers to derive sophisticated controls from fairly simple beginnings. An application developer in the Windows environment only has to provide the glue that sticks all the Windows components together, as well as the application logic itself.
Windows provides the GUI; and the payback is loss of control. At the outset, we stated that in command line programming the programmer has complete control, whereas in Windows programming, Windows has almost complete control. This is a necessity for a number of reasons, chiefly amongst them the handling of all GUI processing and the ability to multi-task.
The Windows Programming Chain
During program start-up, the application registers itself, and asks Windows if there is already an instance running. This allows reuse of common code that is shared amongst instances (like having multiple Word documents open).
Following this (successful) step, the program must then provide a 'message loop', which intercepts and processes messages destined for itself. There is a slight caveat here - if the program does not process a message, and does not hand control back to Windows, any semblance of control breaks down. Simply put, Windows will crash (freeze) : perhaps it is not in as much control as previously stated.
There are ways around this, introduced in later versions (post Windows 3.11) that allow us to terminate applications that are doing this. There is still, however, some faith placed in the application developer that they will hand control back to Windows at some stage after the application has started up.
During the 'message loop', messages which are destined for the application are passed to a special function that contains a number of switch statements to handle the contents of the message, and any parameters passed from Windows to the application. From this function, most of the application's behaviour is sparked. Without these messages, nothing can happen.
What are Windows Messages?
Seeing as how these messages are at the centre of the Windows programming paradigm, it is worth taking a look at what these messages contain. Each one has a type, and two parameters. The type tells us what the message is about (mouse, keyboard, menu, etc.) and the parameters are used to identify the nature of the message.
For example, when a use clicks a control (be it a button, menu item or other control), a message is generated. In the case of menu selection, the message comes through as a type with the identifier 'WM_COMMAND', and a parameter indicating which control (or menu item) was clicked.
Similarly, when the mouse moves within the application's window, a 'WM_MOUSEMOVE' message is sent, with the X and Y coordinates in one parameter, and some information about the status of the buttons and keyboard in the other.
Luckily, not every message needs to be handled by the application. It can, and should, select only those messages which make sense. The rest can be passed to Windows for default processing. In our text editor example, we need only handle menu messages. We can leave all the messages which relate to the behaviour of the text editing control to Windows.
Unless, of course, we want to customise the behaviour of the Text Editing control. Then, we can intercept messages for which we wish to perform custom processing. This is one of the key concepts of advanced Windows programming that allows programmers to extend the functionality available.
Other Windows Functions
Besides the entry point and the main message processing function, there are some other functions which it is useful to be aware of. Each dialog box, for example, must have a message processing function of their own. They will receive dialog box messages for as long as the box is in existence, and the main application will only receive messages during this time if a special (modeless) dialog box is used.
Windows itself also provides a raft of functions for handling Common Dialog Boxes - File Open, Save, and Save As, as well as printer handling and selection of fonts, colours and so on. There are also some functions for handling the loading of DLLs.
Finally, there are functions which provide hooks into specific Windows functionality such as drawing and graphics processing. These should not be confused with video programming using multimedia extensions such as DirectX or OpenGL. The graphics (and sound) processing functionality provided by the native Windows architecture is sufficient for simple applications but is no replacement for the more powerful specialist functionality.
