For a Windows program, the .C source code is only a part of the story. In most cases, the application will also incorporate an .H header file and, almost always, a .RES resource file. These two elements will be discussed in later chapters. For the present, however, there is one more source file that all Windows application sources require, without exception.
When a program is compiled, the compiler processes each .C or .CPP source file (and any included .H header files) to produce an .OBJ (object) file bearing the same name. Subsequently, the linker combines .OBJ and .LIB (library) files to produce the executable program.
For DOS applications, this would be essentially all that’s required. For Windows applications, however, the linker also expects a .DEF (definition) file.
TIP
Applications or DLLs produced using classes defined with the AFX_EXT_CLASS declaration may omit the .DEF definition files. The AFX_EXT_CLASS declaration marks the entire class as exported and, therefore, available for linking by other applications.
This definition file consists of simple ASCII text, but it contains an essential series of instructions for the linker.
;===================================;
; WinHello module-definition file ;
; used by LINK.EXE ;
;===================================;
NAME WinHello
DESCRIPTION ‘Hello, World ... Win98 Style’
EXETYPE WINDOWS
STUB ‘WINSTUB.EXE’
CODE PRELOAD MOVEABLE DISCARDABLE
DATA PRELOAD MOVEABLE MULTIPLE
HEAPSIZE 1024
STACKSIZE 5120
From the top, the .DEF file begins with an application name and a brief description, both of which are optional and could be omitted (however, including a name and description is recommended for clarity and to alleviate future confusion). The third line, EXETYPE, is essentially a binary flag stating either that this is intended to be a Windows executable (WINDOWS) or a dynamic link library (DLL). Alternatively, if this code were being transported to OS/2 for compilation, the specification would be OS2 to identify that operating platform.
The fourth line, STUB, specifies the inclusion, during link, of the WINSTUB.EXE file. The stub program is simply a brief executable that, if the compiled application is called from DOS, displays a warning message stating that the application can be run only from Windows. Similarly, for the OS/2 system, ‘OS2STUB.EXE’ might be specified, or you might design your own stub program to be referenced as ‘MYSTUB.EXE’.
The fifth and sixth lines provide flags identifying how the code and data segments should be treated during execution. Customarily, both the code and data are defined as PRELOAD (load immediately) and MOVEABLE (relocatable in memory). Also as a default, the code segment is normally defined as DISCARDABLE, permitting the memory used by the code segment to be overwritten when memory resources become limited. (Of course, discarding the code segment also means that the application will need to be reloaded from disk before execution can continue.) The MULTIPLE specification for the data segment permits separate data for each active instance of an application. Alternatively, using a SINGLE data specification forces data to be shared between multiple instances.
Next, the HEAPSIZE and STACKSIZE specifications provide default heap and stack memory requirements. The values shown are the suggested defaults and should serve most applications.
The preceding statements can be considered defaults suitable for virtually all applications, and they can be used as a template for future use. The final statements, however, are far more application-specific and, equally, far more important to the application compiling, linking, and executing correctly.
Last, but certainly important—and perhaps also the least familiar element in the .DEF file—is the EXPORTS statement, together with its subsequent list of export labels.
EXPORTS
WndProc
Unlike DOS applications, where the application itself is responsible for all calls to internal procedures, Windows applications depend on exporting principal subprocedures and placing these entry points under the control of the operating system (such as Windows 98), where each will respond to control messages sent by the operating system. For this indirect control to function, the link process must ensure that the addresses of these procedures are known and available; ergo, each must be explicitly exported, which is accomplished by references in the .DEF file.
In this example, only one procedure is exported, WndProc, which provides the principal control structure for the application and forms the absolute minimum required by any Windows application (although the name used may be any valid label desired; it does not need to be named WndProc). However, it is not unusual for applications to have several, dozens, or in very complex situations, even hundreds of exported procedures.
The WinHello.DEF and WinHello.C files provide the minimum necessary to compile an executable Windows program.
TIP
Using MFC, the .DEF define files can be omitted entirely, as will be shown in later examples.
For future applications, this chapter provides a second program, which uses a slightly different approach. The next example is provided as a generic template for your own application development and also to demonstrate a second style for application development.