14. Advanced Programming Topics

	Chapter 20 - Concepts and Tools for Windows Applications
	Visual C++ 6: The Complete Reference
	Chris H. Pappas and William H. Murray, III

Copyright 1998 The McGraw-Hill Companies

---

	Windows Fundamentals

	Windows applications can be developed using a procedure-oriented approach in either C or C++. It is also possible to use an object-oriented approach when programming in C++. All approaches bring together point-and-shoot control, pop-up menus, and the ability to run applications written especially for the Windows environment. The purpose of this portion of the chapter is to introduce you to Windows concepts and vocabulary fundamentals. The graphics user interface is the interface of the future, and Windows gives you the ability to develop that code now!

	The Windows Environment

	Windows is a graphics-based multitasking operating system. Programs developed for this environment (those written specifically for Windows) all have a consistent look and command structure. To the user, this makes learning each successive Windows application easier.

	To help in the development of Windows applications, Windows provides numerous built-in functions that allow for the easy implementation of pop-up menus, scroll bars, dialog boxes, icons, and many other features that represent a user-friendly interface. It is easy to take advantage of the extensive graphics programming language provided with Windows, and easily format and output text in a variety of fonts and pitches.

	Windows permits the application’s treatment of the video display, keyboard, mouse, printer, serial port, and system timers in a hardware-independent manner. Device or hardware independence allows the same application to run identically on a variety of computers with differing hardware configurations.

	Note		For those interested in the Java programming language, pay particular attention to this chapter. Many of the terms and concepts once relegated to C and C++ Windows development have found their way into many Java applications and applets.

	Windows Advantages

	There are numerous advantages for Windows users and programmers alike over the older DOS text-based environment. Windows provides several major programming capabilities that include a standardized graphics interface, a multitasking capability, an OOP approach in programming, memory control, hardware independence, and the use of dynamic link libraries (DLLs).

	The Graphics User Interface (GUI)

	The most noticeable Windows feature is the standardized graphics user interface, which is also the most important one for the user. All versions of Windows are based on the same standardized interface. The consistent interface uses pictures, or icons, to represent disk drives, files, subdirectories, and many of the operating system commands and actions. Figure 20-1 shows a typical Windows application.

	Figure 20-1: Paint is a typical Windows application

	Under Windows, program names appear in caption bars. Many of the basic file manipulation functions are accessed through the program’s menus by pointing and clicking with the mouse. Most Windows programs provide both a keyboard and a mouse interface. Although you can access most Windows functions with just the keyboard, the mouse is the preferred tool of most users.

	A similar look and feel is common to all Windows applications. Once a user learns how to manipulate common Windows commands, each new application becomes easier to master. For example, compare the Microsoft Excel screen shown in Figure 20-2 with the Microsoft Word screen shown in Figure 20-3.

	Figure 20-2: Microsoft’s Excel program

	Figure 20-3: Microsoft’s Word program

	These screens illustrate the similarity between applications, including common File and Edit options. Compare the options in both of these applications with the Paint application illustrated earlier in Figure 20-1.

	The consistent user interface provides advantages for the programmer also. For example, it is possible to tap into built-in Windows functions for constructing menus and dialog boxes. All menus have the same style keyboard and mouse interface because Windows, rather than the programmer, handles its implementation.

	The Multitasking Environment

	The Windows multitasking environment allows the user to have several applications, or several instances of the same application, running at the same time. The screen in Figure 20-4 shows two Windows applications running at the same time. Each application occupies a rectangular window on the screen. At any given time, the user can move the windows on the screen, switch between different applications, change the windows’ sizes, and exchange information from window to window.

	Figure 20-4: Windows allows multiple applications to run at the same time

	The example shown in Figure 20-4 is a group of two concurrently running processes—well, not really. In reality, only one application can be using the processor at any one time. The distinction between a task that is processing and one that is merely running is important. There is also a third state to consider. An application may be in the active state. An active application is one that is receiving the user’s attention. Just as there can be only one application that is processing at any given instant, so too there can be only one active application at a time. However, there can be any number of concurrently running tasks. Partitioning of the microprocessor’s processing time, called time slicing, is the responsibility of Windows. It is Windows that controls the sharing of the microprocessor by using a variety of techniques, including queued input or messages.

	Before multitasking was achieved under Windows, applications assumed they had exclusive control of all the computer’s resources, including the input and output devices, memory, the video display, and even the CPU itself. Under Windows, all of these resources must be shared. Thus, for example, memory management is controlled by Windows instead of by the application.

	Advantages of Using a Queued Input

	Memory, as you have learned, is a shared resource under Windows. However, so are most input devices such as the keyboard and mouse. Thus, when you develop a Windows program in C or C++, it is no longer possible to read directly from the keyboard with a getchar( ) function call or by using the C++ I/O stream. With Windows, an application does not make explicit calls to read from the keyboard or mouse. Rather, Windows receives all input from the keyboard, mouse, and timer in the system queue. It is the queue’s responsibility to redirect the input to the appropriate program since more than one application can be running. This redirection is achieved by copying the message from the system queue into the application’s queue. At this point, when the application is ready to process the input, it reads from its queue and dispatches a message to the correct window.

	Input is accessed with the use of a uniform format called an input message. All input messages specify the system time, state of the keyboard, scan code of any depressed key, position of the mouse, and which mouse button has been pressed (if any), as well as information specifying which device generated the message.

	Keyboard, mouse, and timer messages all have identical formats and are processed in a similar manner. Further, with each message, Windows provides a device-independent virtual keycode that identifies the key, regardless of which keyboard it is on, and the device-dependent scan code generated by the keyboard, as well as the status of other keys on the keyboard, including num lock, alt, shift, and ctrl.

	The keyboard and mouse are a shared resource. One keyboard and one mouse must supply all the input information for each program running under Windows. Windows sends all keyboard input messages directly to the currently active window. Mouse messages, on the other hand, are handled differently. Mouse messages are sent to the window that is physically underneath the mouse cursor, the window with the current focus.

	Another shared resource is timer messages. Timer messages are similar to keyboard and mouse messages. Windows allows a program to set a system timer so that one of its windows receives a message at periodic intervals. This timer message goes directly into the application’s message queue. It is also possible for other messages to be passed into an application’s message queue as a result of the program’s calling certain Windows functions.

	OOPs and Windows Messages

	Object-oriented programming has recently become very popular, but Windows has always employed a pseudo-oops environment. The message system under Windows is the underlying structure used to disseminate information in the multitasking environment. From the application’s perspective, a message is a notification that some event of interest has occurred that may or may not need a specific action. The user may initiate these events by clicking or moving the mouse, changing the size of a window, or making a menu selection. The events can also be initiated by the application itself. For example, a graphics-based spreadsheet could finish a recalculation that results in the need to update a graphics bar chart. In this situation, the application would send an “update window” message to itself.

	Windows itself can also generate messages, as in the case of the “close session” message, in which Windows informs each application of the intent to shut down.

	When considering the role of messages in Windows, use the following points. It is the message system that allows Windows to achieve its multitasking capabilities. The message system makes it possible for Windows to share the processor among different applications. Each time Windows sends a message to the application program, it also grants processor time to the application. In reality, the only way an application can get access to the microprocessor is when it receives a message. Second, messages enable an application to respond to events in the environment. These events can be generated by the application itself, by other concurrently running applications, by the user, or by Windows. Each time an event occurs, Windows makes a note and distributes an appropriate message to the interested applications.

	Managing Memory

	One of the most important shared resources under Windows is system memory. When more than one application is running at the same time, each application must cooperate to share memory in order not to exhaust the total resources of the system. Likewise, as new programs are started and old ones are terminated, memory can become fragmented. Windows is capable of consolidating free memory space by moving blocks of code and data in memory.

	It is also possible to over-commit memory in Windows. For example, an application can contain more code than can actually fit into memory at one time. Windows can discard currently unused code from memory and later reload the code from the program’s executable file.

	Windows applications can share routines located in other executable files. The files that contain shareable routines are called dynamic link libraries (DLLs). Windows includes the mechanism to link the program with the DLL routines at run time. Windows itself is comprised of a large set of dynamic link libraries. To facilitate all of this, Windows programs use a new format of executable file, called the New Executable format. These files include the information Windows needs to manage the code and data segments and to perform the dynamic linking.

	Independence from User Hardware

	Windows also provides hardware or device independence. Windows frees the application developer from having to build programs that take into consideration every possible monitor, printer, and input device available for computers. For example, DOS applications had to be written to include drivers for every possible device the application would encounter. In order to make a DOS application capable of printing on any printer, the application designer had to furnish a different driver for every printer. This required many software companies to write essentially the same device driver over and over again—a LaserJet driver for Microsoft Word for DOS, one for Microsoft Works, and so on.

	Under Windows, a device driver for each hardware device is written once. This device driver can be supplied by Microsoft, the application vendor, or the user. As you know, Microsoft includes a large variety of hardware drivers with Windows.

	It is hardware independence that makes programming a snap for the application developer. The application interacts with Windows rather than with any specific device. It doesn’t need to know what printer is hooked up. The application instructs Windows to draw a filled rectangle, for example, and Windows worries about how to accomplish it on the installed hardware. Likewise, each device driver works with every Windows application. Developers save time, and users do not have to worry about whether each new Windows application will support their hardware configuration.

	Hardware independence is achieved by specifying the minimum capabilities the hardware must have. These capabilities are the minimum specifications required to ensure that the appropriate routines will function correctly. Every routine, regardless of its complexity, is capable of breaking itself down into the minimal set of operations required for a given device. This is a very impressive feature. For example, not every plotter is capable of drawing a circle by itself. As an application developer, however, you can still use the routines for drawing a circle, even if the plotter has no specific circle capabilities. Since every plotter connected to Windows must be capable of drawing a line, Windows is capable of breaking down the circle routine into a series of small lines.

	Windows can specify a set of minimum capabilities to ensure that your application will receive only valid, predefined input. Windows has predefined the set of legal keystrokes allowed by applications. The valid keystrokes are very similar to those produced by the PC-compatible keyboard. Should a manufacturer produce a keyboard that contains additional keys that do not exist in the Windows list of acceptable keys, the manufacturer would also have to supply additional software that would translate these illegal keystrokes into Windows’ legal keystrokes. This predefined Windows legal input covers all the input devices, including the mouse. Therefore, even if someone should develop a four-button mouse, you don’t have to worry. The manufacturer would supply the software necessary to convert all mouse input to the Windows predefined possibilities of mouse-button clicks.

	Dynamic Link Libraries (DLL)

	Dynamic link libraries, or DLLs, provide much of Windows’ functionality. They are used to enhance the base operating system by providing a powerful and flexible graphics user interface. Dynamic link libraries contain predefined functions that are linked with an application program when it is loaded (dynamically), instead of when the executable file is generated (statically). Dynamic link libraries use the .DLL file extension.

	Storing frequently used routines in separate libraries was not an invention of the Windows product. For example, the C/C++ language depends heavily on libraries to implement standard functions for different systems. The linker makes copies of run-time library functions, such as getchar( ) and printf( ), and places them into a program’s executable file. Libraries of functions save each programmer from having to re-create a new procedure for a common operation such as reading in a character or formatting output. Programmers can easily build their own libraries to include additional capabilities, such as changing a character font or justifying text. Making the function available as a general tool eliminates redundant design—a key feature in OOP.

	Windows libraries are dynamically linked. In other words, the linker does not copy the library functions into the program’s executable file. Instead, while the program is executing, it makes calls to the functions in the library. Naturally, this conserves memory. No matter how many applications are running, there is only one copy of the library in RAM at a given time, and this library can be shared.

	When a call is made to a Windows function, the C++ compiler must generate machine code for a far intersegment call to the function located in a code segment in one of the Windows libraries. This presents a problem since until the program is actually running inside Windows, the address of the Windows function is unknown. Doesn’t this sound suspiciously similar to the concept of late binding, discussed in the OOP section of this book? The solution to this problem in Windows is called delayed binding or dynamic linking. Starting with Windows 3.0 and Microsoft C 6.0, the linker allows a program to have calls to functions that cannot be fully resolved at link time. Only when the program is loaded into memory, to be run, are the far function calls resolved.

	Special Windows import libraries are included with the C/C++ compiler; they are used to properly prepare a Windows program for dynamic linking. For example, the import library USER32.DLL is the import library that contains a record for each Windows function that your program can call. This record defines the Windows module that contains this function and, in many cases, an ordinal value that corresponds to the function in the module.

	Windows applications typically make a call to the Windows PostMessage( ) function. When your application is linked at compile time, the linker finds the PostMessage( ) function listed in USER32.LIB. The linker obtains the ordinal number for the function and embeds this information in the application’s executable file. When the application is run, Windows connects the call your application makes with the actual PostMessage( ) function.

	The Executable Format for Windows

	An executable file format was developed for Windows, and is called the New Executable format. This new format includes a new-style header capable of holding information about dynamic link library functions.

	For example, DLL functions are included for the KERNEL, USER, and GDI modules. These libraries contain routines that help programs carry out various chores, such as sending and receiving messages. The library modules provide functions that can be called from the application program or from other library modules. To the module that contains the functions, the functions are known as exports. The New Executable format identifies these exported functions with a name and an ordinal number. Included in the New Executable format is an Entry Table section that indicates the address of each of these exported functions within the module.

	From the perspective of the application program, the library functions that an application uses are known as imports. These imports use the various relocation tables and can identify the far calls that the application makes to an imported function. Almost all Windows programs contain at least one exported function. This window function is usually located in one of the library modules and is the one that receives window messages.

	This new format also provides the additional information on each of the code and data segments in a program or library. Typically, code segments are flagged as moveable and discardable, while data segments are flagged as moveable. This allows Windows to move code and data segments in memory and even discard code segments if additional memory is needed. If Windows later decides it needs a discarded code segment, it can reload the code segment from the original executable file. Windows has another category called load on call. This defines a program or library code segment that will not be loaded into memory at all unless a function in the code segment is called from another code segment. Through this sophisticated memory-management scheme, Windows can simultaneously run several programs in a memory space that would normally be sufficient for only one program.

	Originally, Windows depended on a module-definition file to specify the linker options just discussed. However, the linker provided with Visual C++ now provides equivalent command-line options for most module definition statements. Thus, a program now designed for Windows does not usually require a module definition file to access these capabilities.

Books24x7.com, Inc 2000 –