Chapter 1: Windows and Visual C++ .NET
In the early nineties, the battle was for the desktop operating system. Now that battle is over, and Microsoft Windows runs on the vast majority of personal computer systems. This chapter summarizes the low-level Windows programming model (Win32, in particular) and shows you how the Microsoft Visual C++ .NET components work together to help you write applications for Windows. Along the way, you might learn some new things about Windows as well.
No matter which development tools you use, programming for Windows is different from old-style batch-oriented or transaction-oriented programming. To get started, you need to know some Windows fundamentals. As a frame of reference, we'll use the well-known MS-DOS programming model. Even if you don't currently program for plain MS-DOS, you're probably familiar with it.
When you write an MS-DOS–based application in C, the only absolute requirement is a function named main. The operating system calls main when the user runs the program, and from that point on, you can use any programming structure you want. If your program needs to get user keystrokes or otherwise use operating system services, it calls an appropriate function, such as getchar, or perhaps uses a character-based windowing library.
When the Windows operating system launches a program, it calls the program's WinMain function. Somewhere your application must have WinMain, which performs some specific tasks. Its most important task is creating the application's main window, which must have its own code to process messages that Windows sends it. An essential difference between a program written for MS-DOS and a program written for Windows is that an MS-DOS–based program calls the operating system to get user input but a Windows-based program processes user input via messages from the operating system.
| Note |
Many development environments for Windows, including Visual C++ .NET with Microsoft Foundation Class (MFC) library version 7.0, simplify programming by hiding the WinMain function and structuring the message-handling process. When you use the MFC library, you need not write a WinMain function, but it is essential that you understand the link between the operating system and your programs. |
Most messages in Windows are strictly defined and apply to all programs. For example, a WM_CREATE message is sent when a window is being created, a WM_LBUTTONDOWN message is sent when the user presses the left mouse button, a WM_CHAR message is sent when the user types a character, and a WM_CLOSE message is sent when the user closes a window. All messages have two 32-bit parameters that convey information such as cursor coordinates, key code, and so forth. Windows sends WM_COMMAND messages to the appropriate window in response to user menu choices, dialog box button clicks, and so on. Command message parameters vary depending on the window's menu layout. You can define your own messages, which your program can send to any window on the desktop. These user-defined messages actually make C++ look a little like Smalltalk.
Don't worry yet about how these messages are connected to your code. That's the job of the application framework. Be aware, though, that the Windows message processing requirement imposes a lot of structure on your program. Don't try to force your Windows-based programs to look like your old MS-DOS programs. Study the examples in this book, and then be prepared to start fresh.
Many MS-DOS programs write directly to the video memory and the printer port. The disadvantage of this technique is the need to supply driver software for every video board and every printer model. Windows introduced a layer of abstraction called the Graphics Device Interface (GDI). Windows provides the video and printer drivers, so your program doesn't need to know the type of video board and printer attached to the system. Instead of addressing the hardware, your program calls GDI functions that reference a data structure called a device context. Windows maps the device context structure to a physical device and issues the appropriate input/output instructions. The GDI is almost as fast as direct video access, and it allows different applications written for Windows to share the display.
Later in the book, we'll look at GDI+. As you might guess, GDI+ is the successor to GDI. The services of GDI+ are exposed through a set of C++ classes deployed as managed code—that is, code running under the common language runtime. GDI+ introduces several enhancements over classic GDI, including gradient brushes, cardinal splines, independent path objects, scalable regions, alpha blending, and multiple image formats.
To do data-driven programming in MS-DOS, you must either code the data as initialization constants or provide separate data files for your program to read. When you program for Windows, you store data in a resource file using a number of established formats. The linker combines this binary resource file with the C++ compiler's output to generate an executable program. Resource files can include bitmaps, icons, menu definitions, dialog box layouts, and strings. They can even include custom resource formats that you define.
You use a text editor to edit a program, but you generally use WYSIWYG (what you see is what you get) tools to edit resources. If you're laying out a dialog box, for example, you select elements (buttons, list boxes, and so forth) from an array of icons called a control palette, and you position and size the elements with the mouse. Visual C++ .NET has graphics resource editors for all standard resource formats.
With each new version of Windows, memory management gets easier. If you've heard horror stories about locking memory handles, thunks, and burgermasters, don't worry. That's all in the past. Today you simply allocate the memory you need, and Windows takes care of the details. Chapter 10 describes current memory management techniques for Win32, including virtual memory and memory-mapped files.
Chapter 22 includes information about creating MFC extension DLLs and regular DLLs.
Early Windows programmers wrote applications in C for the Win16 application programming interface (API). Of course, today few folks write 16-bit applications. Most developers write applications using the Win32 API. The main difference between the Win16 functions and the Win32 functions is that in the latter, many of the parameters have been widened. So while the Windows API has changed over the years (and continues to change), developers using the MFC library have remained insulated from these changes because the MFC standard was designed to work with either Win16 or Win32 underneath.