Part D: Directions of MS—DOS
`
`2. Resource script: The resource script is an ASCII file that generally has the extension
`.RC. This file contains definitions of menus, dialog boxes, string tables, and keyboard
`accelerators used by the program. The resource script can also reference other files
`that contain icons, cursors, bitmaps, and fonts in binary form, as well as other read—
`only data defined by the programmer. When a program is running, Windows loads
`resources into memory only when they are needed and in most cases can discard
`them if additional memory space is required.
`'
`
`SAMPLERC, the resource script for the SAMPLE program, is shown in Figure 17—12; it
`contains only the definition of the menu used in the program.
`#include "sample.h"
`
`Sample MENU
`BEGIN
`
`POPUP "&Typeface"
`BEGIN
`
`MENUITEM "&Script",
`MENUITEM "&Modern",
`MENUITEM "&Roman",
`
`IDM_SCRIPT, CHECKED
`IDM_MODERN
`IDM_ROMAN
`
`END
`
`END
`
`Figure 17-12. The resource scriptfor the SAMPLEprogram.
`
`
`
`3. Header (or include) file: This file, with the extension .H, can contain definitions of
`constants or macros, as is customary in C programming. For Windows programs, the
`header file also reconciles constants used in both the resource script and the pro-
`gram source—code file. For example, in the SAMPLERC resource script, each item in
`the pop-up menu (Script, Modern, and Roman) also includes an identifier——
`IDM_SCRIPT, IDM_MODERN, and IDM_ROMAN, respectively. These identifiers
`are merely numbers that Windows uses to notify the program of the user’s selection
`of a menu item. The same names are used to identify the menu selection in the C
`source-code file. And, because both the resource compiler and the source-code com-
`piler must have access to these identifiers, the header file is included in both the
`resource script and the source—code file.
`
`The header file for the SAMPLE program, SAMPLEH, is shown in Figure 17—13.
`#define IBM—SCRIPT W
`#de fine IDM_MODERN 2
`#define IBM—ROMAN
`3
`
`Figure 17-13. The SAMPLEH headerfile.
`
`4. Module-definition file: The module—definition file generally has a .DEF extension.
`The Windows linker uses this file in creating the executable .EXE file. The module—
`definition file specifies various attributes of the program’s code and data segments,
`and it lists all imported and exported functions in the source-code file. In large pro-
`grams that are divided into multiple code segments, the module-definition file allows
`the programmer to specify different attributes for each code segment.
`
`516
`
`TheMS—DOSEncyclopedia
`
`
`
`OLYMPUS EX. 1010 - 526/1582
`
`

`

`
`
`Article 17: Windows
`
`The module—definition file for the SAMPLE program is named SAMPLEDEF and is
`shown in Figure 17-14.
`'
`NAME
`SAMPLE
`DESCRIPTION .
`'Demonstration Windows Program'
`STUB
`'WINSTUB.EXE'
`CODE
`MOVABLE
`DATA
`MOVABLE MULTIPLE
`HEAPSIZE
`1024
`STACKSIZE
`4096
`EXPORTS
`WndProc
`
`Figure 17-14. The SAMPLEDEF module—definitionfile.
`
`5. Make file: To facilitate construction of the executable file from these different com-
`
`ponents, Windows programmers often use the MAKE program to compile only those
`files that have changed since the last time the program was linked. To do this, the
`programmer first creates an ASCII text file called a make file. By convention, the
`make file has no extension.
`
`The make file for the SAMPLE program is named SAMPLE and is shown in Figure
`17—15. The programmer can create the SAMPLE.EXE executable file by executing
`C>MAKE SAMPLE <Enter>
`
`A make file often contains several sections, each beginning with a target filename,
`followed by a colon and one or more dependent filenames, such as
`
`sample.obj
`
`: sample.c sample.h
`
`If either or both the SAMPLEC and SAMPLEH files have a later creation time than
`
`SAMPLEOBJ, then MAKE runs the program or programs listed immediately below.
`In the case of the SAMPLE make file, the program is the C compiler, and it compiles
`the SAMPLEC source code:
`
`cl —c —Gsw -W2 —de sample.c
`
`Thus, if the programmer changes only one of the several files used in the develop-
`ment of SAMPLE, then running MAKE ensures that the executable file is brought up
`to date, while carrying out only the required steps.
`
`: sample.c sample.h
`sample.obj
`cl —c —Gsw —W2 —de sample.c
`
`sample.res : sample.rc sample.h
`rc -r sample.rc
`
`sample.exe : sample.obj sample.def sample.res
`link4 sample,
`/align:16,
`/map /line, slibw, sample
`to sample.res
`mapsym sample
`
`Figure 1 7-15. The makefilefor the SAMPLEprogram.
`
`Section 11: Programming in the MS—DOS Environment
`
`5 1 7
`
`OLYMPUS EX. 1010 - 527/1582
`
`

`

`
`
`Part D: Directions of MS~DOS
`
`Construction of a Windows program
`
`The make file shows the steps that create a program’s .EXE file from the various
`components:
`
`1.
`
`Compiling the source-code file:
`cl -c -Gsw -W2 —de sample.c
`
`This step uses the CLEXE C compiler to create a QB] obj ect—module file. The com—
`mand line switches are
`
`— ~c: Compiles the program but does not link it. Windows programs must be linked '
`with Windows’ LINK4 linker, rather than with the LINK program the C compiler
`would normally invoke.
`— -Gsw: Includes two switches, —G5 and -Gw. The -Gs switch removes stack checks
`from the program. The —Gw switch inserts special prologue and epilogue code in
`all far functions defined in the program. This special code is required for Win-
`dows’ memory management.
`— -W2: Compiles with warning level 2. This is the highest warning level, and it causes
`the compiler to display messages for conditions that may be acceptable in normal C
`programs but that can cause serious errors in a Windows program.
`— -de: Includes two switches, -Zd and -Zp. The -Zd switch includes line numbers
`in the OB] file — helpful for debugging at the source-code level. The —Zp switch
`packs structures on byte boundaries. The —Zp switch is required, because data
`structures used Within Windows are in a packed format.
`Compiling the resource script:
`
`rc -r sample. re
`
`This step runs the resource compiler and converts the ASCII .RC resource script into a
`binary .RES form. The —r switch indicates that the resource script should be compiled
`but the resources should not yet be added to the program’s .EXE file.
`Linking the program:
`
`link4 sample,
`
`/align:16,
`
`/map /line, slibw, sample
`
`This step uses the special Windows linker, LINK4. The first parameter listed is the
`name of the OB] file. The /align:16 switch instructs LINK4 to align segments in the
`.EXE file on 16-byte boundaries. The /map and /line switches cause LINK4 to create a
`.MAP file that contains program line numbers —again, useful for debugging source
`code. Next, slibw is a reference to the SLIBW.LIB file, which is an import library that
`contains module names and ordinal numbers for all Windows functions. The last
`
`parameter, sample, is the program’s module-definition file, SAMPLE.DEF.
`Adding the resources to the .EXE file:
`
`rc sample . res
`
`518
`
`The MS-DOS Encyclopedia
`
`
`
`OLYMPUS EX. 1010 - 528/1582
`
`

`

`Article 17: Windows
`
`This step runs the resource compiler a second time, using the compiled resource file,
`SAMPLERES. This time, the resource compiler adds the resources to the .EXE file.
`
`
`
`Resource script
`(.RC)
`
`
`
`Header or
`include files
`(.H or .lNC)
`
`Program
`source code
`(.C, .PAS, or .ASM)
`
`
`
`
`
`Module
`definition file
`(.DEF)
`
`
`
`C or Pascal
`RC.EXE
`
`
`Compiler or
`
`Resource compiler
`Macro Assembler
`
`
`
`
`
`
`Compiled resources
`(.RES)
`
`Object module
`(.OBJ)
`
`
`
`LINK4.EXE
`Window linker
`
`Executable
`
`
`without resources
`
`
`(.EXE)
`
`
`
`RC.EXE
`Resource compiler
`
`
`
`
`
`Executable
`
`(.EXE)
`
`
`
`Map file
`(.MAP)
`
`MAPSYMEXE
`Converts map file
`to symbol file
`
`
`
`Symbol file
`(.3YM)
`
`Figure 17—16. A block diagram showing the creation ofa Windows .EXEfile.
`
`Section 11: Programming in the MS—DOS Environment
`
`519
`
`
`
`OLYMPUS EX. 1010 - 529/1582
`
`

`

`
`
`Part D: Directions of MS-DOS
`
`‘ 5. Creating a symbol (.SYM) file from the linker’s map (.MAP) file:
`mapsym sample
`
`This step is required for symbolic debugging with SYMDEB.
`
`Figure 17-16 on the preceding page shows how the various components of a Windows pro-
`gram fit into the creation of a .EXE file.
`’
`
`Program initialization
`
`The SAMPLEC program shown in Figure 17-11 contains some code that appears in almost
`every Windows program. The statement
`#include <windows.h>
`
`appears at the top of every Windows source-code file written in C. The WINDOWSH file,
`provided with the Microsoft Windows Software Development Kit, contains templates for
`all Windows functions, structure definitions, and #define statements for many mnemonic
`identifiers.
`
`Some of the variable names in SAMPLEC may look unusual to C programmers because
`they begin with a prefix notation that denotes the data type of the variable. Windows
`programmers are encouraged to use this type of notation. Some of the more common
`prefixes are
`
`Prefix
`
`Data Type
`
`i or n
`w
`1
`dw
`h
`sz
`lpsz
`lpfn
`
`‘
`
`Integer (16-bit signed integer)
`Word (16-bit unsigned integer)
`Long (32-bit signed integer)
`Doubleword (32-bit unsigned integer)
`Handle (16-bit unsigned integer)
`Null-terminated string
`Long pointer to null-terminated string
`Long pointer to a function
`
`The program’s entry point (following some startup code) is the WinMain function,
`which is passed the following parameters: a handle to the current instance of the
`program (hInstance), a handle to the most recent previous instance of the program
`(hPrevInstance), a long pointer to the program’s command line (lpsszdLine), and a
`number (nCmdShow) that indicates whether the program should initially be displayed as a
`normally sized window or as an icon.
`
`The first job SAMPLE performs in the WinMain function is to register a window class — a
`structure that describes characteristics of the windows that will be created in the class.
`
`These characteristics include background color, the type of cursor to be displayed in the
`window, the window’s initial menu and icon, and the window function (the structure
`member called lpanndProc).
`
`520
`
`The MS—DOS Encyclopedia
`
`
`
`OLYMPUS EX. 1010 - 530/1582
`
`

`

`Article 17: Windows
`
`Multiple instances of a program can share the same window class, so SAMPLE registers the
`Window class only for the first instance of the program:
`
`if (threvInstance)
`
`CS_HREDRAW : CS_VREDRAW ;
`= WndProc ;
`
`( w
`
`ndclass.style
`wndclass.lpanndProc
`
`wndclass.CbClsExtra
`wndclass.candExtra
`wndclass.hInstance
`wndclass.hIcon
`wndclass.hCursor
`wndclass.herackground
`wndclass.lpszMenuName
`wndclass.lpszClassName
`
`= 0 ;
`= O
`;
`= hInstance ;
`V
`= NULL ;
`IDC_ARROW)
`(NULL,
`LoadCursor
`GetStockObject
`(WHITE_BRUSH)
`szAppName ;
`szAppName ;
`
`ll
`
`;
`;
`
`Registerclass (&wndclass)
`l
`
`;
`
`The SAMPLE program then creates a window using the CreateWindow call, displays it to
`the screen by calling ShowWindow, and updates the client area by calling UpdateWindow:
`
`hWnd = Createwindow (szAppName, "Demonstration Windows Program",
`WS_OVERLAPPEDWINDOW,
`I
`(int) CW_USEDEFAULT, 0,
`(int) CW_USEDEFAULT,O,
`NULL, NULL, hInstance, NULL)
`ShowWindow (hWnd, nCmdshow)
`;
`UpdateWindow (hWnd)
`;
`
`;
`
`The first parameter to CreateWindow is the name of the window class. The second param-
`eter is the actual text that appears in the window’s title bar. The third parameter is the style
`of the Window— in this case, the WINDOW/SH identifier WS_OVERLAPPEDWINDOW
`The WS_OVERLAPPEDWINDOW is the most common window style. The fourth through
`seventh parameters specify the initial position and size of the window. The identifier
`CW_USEDEFAULT tells Windows to position and size the window according to the default
`rules.
`
`After Creating and displaying a Window, the SAMPLE program enters a piece of code
`called the message loop:
`
`while (GetMessage (&msg, NULL, 0, 0))
`
`;
`
`;
`
`( T
`
`ranslateMessage (&msg)
`DispatchMessage (&msg)
`l
`return msg . wParam ;
`
`Thisloopcontinuesto executeuntilthe GetMessagecallreturnszero. Whenthathappens,
`
`theprograminstanceterminatesandthememoryrequiredfortheinstanceisfreed.
`
`Section 11: Programming in the MS—DOS Environment
`
`52 1
`
`
`
`{
`l
`E
`
`,
`
`
`
`i
`
`l
`
`OLYMPUS EX. 1010 - 531/1582
`
`

`

`
`
`Part D: Directions of MS-DOS
`
`The Windows messaging system
`
`Interactive programs written for the normal MS—DOS environment generally obtain user
`input only from the keyboard, using either an MS—DOS or a ROM BIOS software interrupt
`to check for keystrokes. When the user types something, such programs act on the key—
`stroke and then return to wait for the next keystroke.
`
`,
`
`Programs written for Windows, however, can receive user input from a variety of sources,
`including the keyboard, the mouse, the Windows timer, menus, scroll bars, and controls,
`such as buttons and edit boxes.
`
`Moreover, a Windows program must be informed of other events occurring within the
`system. For instance, the user of a Windows program might choose to make its window
`smaller or larger. Windows must make the program aware of this change so that the pro-
`gram can adjust its screen output to fit the new window size. Thus, for example, if a Win-
`dows program is minimized as an icon and the user maximizes its window to fill the full
`screen, Windows must inform the program that the size of the client area has changed
`and needs to be re—created.
`
`Windows carries out this job of keeping a program informed of other events through the
`use of formatted messages. In effect, Windows sends these messages to the program. The
`Windows program receives and acts upon the messages.
`
`This messaging makes the relationship between Windows and a Windows program much
`different from the relationship between MS—DOS and an MS—DOS program. Whereas
`MS-DOS does not provide information until a program requests it through an MS-DOS
`function call, Windows must continually notify a program of all the events that affect its
`window.
`
`Window messages can be separated into two major categories: queued and nonqueued.
`
`Queued messages are similar to the keyboard information an MS—DOS program obtains
`from MS—DOS. When the Windows user presses a key on the keyboard, moves the mouse,
`or presses one of the mouse buttons, Windows saves information about the event (in the
`form of a data structure) in the system message queue. Each message is destined for a par-
`ticular window in a particular instance of a Windows program. Windows therefore deter-
`mines which window should get the information and then places the message in the
`instance’s own message queue.
`
`A Windows program retrieves information from its queue in the message loop:
`while (Get-Message (&msg, NULL, O,\O))
`(
`TranslateMessage (amsg)
`DispatchMessage (&msg)
`l
`
`,
`
`‘
`
`;
`
`;
`
`
`
`The msg variable is a structure. During the GetMessage call, Windows fills in the fields of
`this structure with information about the message. The fields are as follows:
`
`522
`
`The MS-DOS Encyclopedia
`
`  
`
`

 


`
`OLYMPUS EX. 1010 - 532/1582
`
`

`

`Article 17: Windows
`
`O
`0
`
`hwnd: The handle for the window that is to receive the message.
`iMessage: A numeric code identifying the type of message (for example, keyboard
`or mouse).
`
`_
`
`0
`0
`
`O wPamm: A 16-bit value containing information specific to the message. See The
`'Windows Messages below.
`[Paramz A 32—bit value containing information specific to the message.
`time: The time, in milliseconds, that the message was placed in the queue. The time
`is a 52-bit value relative to the time at which the current Windows session began.
`ptx: The horizontal coordinate of the mouse cursor at the time the event occurred.
`pt.3/: The vertical coordinate of the mouse cursor at the time the event occurred.
`
`O
`0
`
`‘
`
`GetMessage always returns a nonzero value except when it receives a quit message. The
`quit message causes the message loop to end. The program should then terminate and
`return control to Windows.
`'
`
`Within the message loop, the TranslateMessage function translates physical keystrokes into
`character-code messages. Windows places these translated messages into the program’s
`message queue.
`
`The DispatchMessage function essentially makes a call to the window function of the win—
`dow specified by the hwnd field. This window function (WndProc in SAMPLE) is indicated
`in the lpanndProc field of the window class structure.
`
`When DispatchMessage passes the message to the window function, Windows uses the
`first four fields of the message structure as parameters to the function. The window func—
`tion can then process the message. In SAMPLE, for instance, the four fields passed to
`WndProc are hwnd (the handle to the window), tMessage (the numeric message iden-
`tifier), wPozmm, and lParam. Although Windows does not pass the time and mouse—
`position information fields as parameters to the window function, this information is
`available through the Windows functions GetMessageTime and GetMessagePos.
`
`A Windows program obtains only a few specific types of messages through its message
`queue. These are keyboard messages, mouse messages, timer messages, the paint message
`that tells the program it must re-create the client area of its window, and the quit message
`that tells the program it is being terminated.
`
`In addition to the queued messages, however, a program’s window function also receives
`many nonqueued messages. Windows sends these nonqueued messages by bypassing the
`message loop and calling the program’s window function directly.
`
`Many of these nonqueued messages are derived from queued messages. For example,
`when the user clicks the mouse on the menu bar, a mouse-click message is placed in the
`program’s message queue. The GetMessage function retrieves the message and the Dis-
`patchMessage function sends it to the program’s window function. However, because this
`mouse message affects a nonclient area of the window (an area outside the window’s cli-
`ent area), the window function normally does not process it. Instead, the function passes
`the message back to Windows. In this example, the message tells Windows to invoke a
`pop—up menu. Windows calls up the menu and then sends the window function several
`nonqueued messages to inform the program of this action.
`
`Section 11.- Programming in the MS-DOS Environment
`
`523
`
`
`
`i I
`
`,
`
`g
`
`.
`5
`
`OLYMPUS EX. 1010 - 533/1582
`
`

`

`
`
`Part D: Directions of MS—DOS
`
`A Windows program is thus message driven. Once a program reaches the message loop,
`it acts only when the window function receives a message. And, although a program
`receives many messages that affect the window, the program usually processes only some
`of them, sending the rest to Windows for normal default processing.
`
`The Windows messages
`
`Windows can send a window function more than 100 different messages. The
`WINDOWSH header file includes identifiersfor all these messages so that C programmers
`do not have to remember the message numbers. Some of the more common messages and
`the meanings of the wPamm and lPamm parameters are discussed here:
`
`WM__CREATE. Windows sends a window function this nonqueued message while pro—
`cessing the CreateWindow call. The lPamm parameter is a pointer to a creation structure.
`A window function can perform some program initialization during the WM_CREATE .
`message.
`
`W_MOVE. Windows sends a windowfunction the nonqueued WM_MOVE message
`when the window has been moved to another part of the display. The lPamm parameter
`gives the new coordinates of the window relative to the upper left corner of the screen.
`
`WVLSIZE. This nonqueued message indicates that the size of the window has been
`changed. The new size is encoded in the lPamm parameter. Programs often save this
`window size for later use.
`
`WM_PAINT This queued message indicates that a region in the window’s client area
`needs repainting. (The message queue can contain only one WM_ PAINT message.)
`
`WM_COMMAND. This nonqueued message signals a program that a user has selected a
`menu item or has triggered a keyboard accelerator. Child-window controls also use
`WM_COMMAND to send messages to the parent window.
`
`W_KEYDOWN The wPamm parameter of this queued message is a virtual key code
`that identifies the key being pressed. The [Pamm parameter includes flags that indicate
`the previous key state and the number of keypresses the message represents.
`
`WM_KEYUP. This queued message tells a window function that a key has been released.
`The wPamm parameter is a virtual key code.
`
`W_CHAR. This queued message is generated from WM_ KEYDOWN messages during
`the TranslateMessage call. The wPamm parameter is the ASCII code of a keyboard key.
`
`m/LMOUSEMOVE. Windows uses this queued message to tell a program about mouse
`movement. The lPamm parameter contains the coordinates of the mouse relative to the '
`upper left corner of the client area of the window. The wPamm parameter contains flags
`that indicate whether any mouse buttons or the Shift or Ctrl keys are currently pressed.
`
`W_XBUTTONDOWN. This queued message tells a program that a button on the mouse
`was depressed while the mouse was in the window’s, client area. The xcan be either L, R,
`or M for the left, right, or middle mouse button. The wPamm and [Pamm parameters are
`the same as for WM_MOUSEMOVE.
`
`524
`
`The MS—DOS Encyclopedia
`
`
`
`OLYMPUS EX. 1010 - 534/1582
`
`

`

`
`
`Article 17: Windows
`
`WM_XBUTTONUP. This queued message tells a program that the user has released a
`mouse button.
`
`WM_XBUTTONDBLCLK. When the user double-clicks a mouse button, Windows
`generates a WM_xBUTTONDOWN message for the first click and a queued
`WM_xBUTTONDBLCLK message for the second click.
`
`WM_ TIMER. When a Windows program sets a timer with the SetTimer function,
`Windows places a WM_TIMER message in the message queue at periodic intervals.
`The wPamm parameter is a timer ID. (If the message queue already contains a
`WM_TIMER message, Windows does not add another one to the queue.)
`
`W_VSCROLL. A Windows program that includes a vertical scroll bar in its window
`receives nonqueued WM_VSCROLL messages indicating various types of scroll-bar
`manipulation.
`
`WM_- HSCROLL. This nonqueued message indicates a user is manipulating a horizontal
`scroll bar.
`
`WM_CLOSE. Windows sends a window function this nonqueued message when the user
`has selected Close from the window’s system menu. A program can query the user to de-
`termine whether any action, such as saving a file to disk, is needed before the program
`is terminated.
`
`. WM_QUERYEADSESSION This nonqueued message indicates that the user is shutting
`down Windows by selecting Close from the MS-DOS Executive system menu. A program
`can request the user to verify that the program should be ended. If the window function '
`returns a zero value from the message, Windows does not end the session.
`
`WM_. DESTROY. This nonqueued message is the last message a window function receives
`before the program ends. A window function can perform some last-minute cleanup while
`processing WM_ DESTROY.
`
`WM_QUIT. This is a queued message that never reaches the window function because it
`causes GetMessage to return a zero value that causes the program to exit the message loop.
`
`Message processing
`
`Programmers can choose to process some messages and ignore others in the window
`function. Messages that are ignored are generallypassed on to the function
`Def WindowProc for default processing within Windows.
`
`Because Windows eventually has aCCess to messages that a window function does not
`process, it can send a program messages that might otherwise be regarded as pertaining to
`system functions —— for example, mouse messages that occur in a nonclient area of the win-
`dow, or system keyboard messages that affect the menu. Unless these messages are passed
`on to Def WindowProc, the menu and other system functions do not work properly.
`
`A program can, however, trap some of these messages to override Windows’ default pro—
`cessing. For example, when Windows needs to repaint the nonclient area of a window (the
`title bar, system-menu box, and scroll bars), it sends the window function a WM_NCPAINT
`
`1
`
`Section11:ProgrammingintheMS—DOSEnvironment
`
`525
`
`OLYMPUS EX. 1010 - 535/1582
`
`

`

`
`
`Part D: Directions of MS-DOS
`
`(nonclient paint) message. The window function normally passes this message to
`Def WindowProc, which then calls routines to update the nonclient areas of the window.
`The program can, however, choose to process the WM_ NCPAINT message and paint the
`nonclient area itself. A program that does this can, for example, draw its own scroll bars.
`
`The Windows messaging system also notifies a program of important events occurring
`outside its window. For example, if the MS-DOS Executive were simply to end the Win-
`dows session when the user selects the Close option from its system menu, then applica-
`tions that were still running would not have a chance to save changed files to disk. Instead,
`when the user selects Close from the last instance of the MS-DOS Executive’s system
`menu, the MS-DOS Executive sends a WM_QUERYENDSESSION message to each cur-
`rently running application. If any application responds by returning a zero value, the MS-
`DOS Executive does not end the Windows session.
`
`Before responding, an application can process the WM_QUERYENDSESSION message
`and display a message box asking the user if a file should be'saved. The message box
`should include three buttons labeled Yes, No, and Cancel. If the user answers Yes, the pro-
`gram can save the file and then return a nonzero value to the WM_QUERYENDSESSION
`message. If the user answers No, the program can return a nonzero value without saving
`the file. But if the user answers Cancel, the program should return a zero value so that
`the Windows session will not be ended. If a program does not process the
`WM_QUERYENDSESSION message, Def WindowProc returns a nonzero value.
`
`When a user selects Close from the system menu of a particular instance of an application,
`rather than from the MS—DOS Executive’s menu, Windows sends the window function a
`WM_CLOSE message. If the program has an unsaved file loaded, it can query the user with
`a message box— possibly the same one displayed when WM_QUERYENDSESSION is
`processed. If the user responds Yes to the query, the program can save the file and then
`call DestroyWindow. If the user responds No, the program can call DestroyWindOW
`without saving the file. If the user responds Cancel, the window function does not call
`DestroyWindow and the program will not be terminated. If a program does not process
`WM_CLOSE messages, Def WindowProc calls DestroyWindow.
`
`Finally, a window function can send messages to other window functions, either within
`the same program or in other programs, with the Windows SendMessage function. This
`function returns control to the calling program after the message has been processed. A
`program can also place messages in a program’s message queue with the PostMessage
`function. This function returns control immediately after posting the message.
`
`For example, when a program makes changes to the WIN.INI file.(a file containing
`Windows initialization information), it can notify all currently running instances of these
`changes by sending them a WM_WININICHANGE message:
`
`SendMessage (—1, WM_WININICHANGE, 0, 0L)
`
`;
`
`The -1 parameter indicates that the message is to be sent to all window functions of
`all currently running instances. Windows calls the window functions with the
`WM_WININICHANGE message and then returns control to the program that sent the
`message.
`'
`
`526
`
`The MS-DOS Encyclopedia
`
`
`
`OLYMPUS EX. 1010 - 536/1582
`
`

`

`
`
`‘
`
`
`
`{
`
`I
`
`-
`
`Article 17: Windows
`
`SAMPLE’s message processing
`
`The SAMPLE program shown in Figure 17-11 processes only four messages:
`WM_COMMAND, WM_SIZE, WM__PAINT, and WM_ DESTROY. All other messages are
`passed to Def WindowProc. As is typical with most Windows programs written in C,
`SAMPLE uses a switch and case construction for processing messages.
`The WM_COMMAND message signals the program that the user has selected a new font
`from the menu. SAMPLE first obtains a handle to the menu and removes the checkmark
`from the previously selected font:
`
`;
`hMenu = GetMenu (hWnd)
`CheckMenuItem (hMenu, nCurrentFont, MF_UNCHECKED)
`
`;
`
`The value of wParam in the WM_COMMAND message is the menu ID of the newly
`selected font. SAMPLE saves that value in a static variable (nCurrent Font) and then places a
`checkmark on the new menu choice:
`
`nCurrentFont = wParam ;
`CheckMenuItem (hMenu, nCurrentFont, MF_CHECKED)
`
`;
`
`Because the typeface has changed, SAMPLE must repaint its display. The program does
`not repaint it immediately, however. Instead, it calls the InvalidateRect function:
`
`InvalidateReet
`
`(hWnd, NULL, TRUE)
`
`;
`
`This causes a WM_PAINT message to be placed in the program’s message queue. The
`NULL parameter indicates that the entire client area should be repainted. The TRUE
`parameter indicates that the background should be erased.
`
`The WM_SIZE message indicates that the size of SAMPLE’s client area has changed.
`SAMPLE simply saves the new dimensions of the client area in two static variables:
`xClient
`yClient
`
`II[I
`
`LOWORD (lParam)
`HIWORD (lParam)
`
`;
`;
`
`The LOWORD and HIWORD macros are defined in WINDOWSH.
`
`Windows also places a WM_PAINT message in SAMPLE’S message queue when the size
`of the client area has changed. As is the case with WM_COMMAND, the program does
`not have to repaint the client area immediately, because the WM_ PAINT message is in the
`message queue.
`
`SAMPLE can receive a WM_PAINT message for many reasons. The first WM_PAINT mes-
`
`sage itreceives results fromcallingUpdateWindowintheWinMainfunction. Later, ifthe
`
`current font is changed from the menu, the program itself causes a WM_ PAINT message
`to be placed in the message queue by calling InvalidateRect. Windows also sends a win-
`dow function a WM_PAINT message whenever the user changes the size of the window
`
`orwhenpartofthewindowpreviouslycoveredbyanotherWindowisuncovered.
`
`Programs begin processing WM_ PAINT messages by calling Begin Paint:
`
`BeginPaint
`
`(hWnd, aps)
`
`;
`
`Section II: Programming in the MS—DOS Environment
`
`527
`
`OLYMPUS EX. 1010 - 537/1582
`
`

`

`
`
`Part D: Directions of MS—DOS
`
`The SAMPLE program then creates a font based on the current size of the client area and
`the current typeface selected from the menu:
`'
`
`hFont = CreateFont
`
`(yClient, xClient / 8,
`0, 0, 400, 0, 0,, 0, OEmCHARSET,
`OUT_STROKE__PRECIS , OUT_STROKE_PRECI S ,
`DRAFT_QUALITY,
`(BYTE) VARIABLEJITCH I
`cFamily [nCurrentFont — IDM_SCRIPT],
`stace [nCurrentFont — IDM_SCRIPT])
`
`;
`
`The font is selected into the device context (a data structure internal to Windows that
`
`describes the characteristics of the output device); the program also saves the original
`device—context font:
`
`hFont = Selectobject
`
`(ps.hdc, hFont)
`
`And the word Windows is displayed:
`
`TextOut
`
`(ps.hdc, 0, 0,
`
`"Windows", 7)
`
`;
`
`,-
`
`The original font in the device context is then selected, and the font that was created is
`now deleted:
`
`Deleteobject
`
`(Selectobject
`
`(ps.hdc, hFont))
`
`;
`
`Finally, SAMPLE calls EndPaint to signal Windows that the client area is now updated and
`valid:
`
`EndPaint
`
`(hWnd, &ps)
`
`;
`
`I
`
`Although the processing of the WM_ PAINT message in this program is simple, the
`method used is common to all Windows programs. The Begin Paint and End Paint func-
`tions always occur in pairs, first to get information about the area that needs repainting
`and then to mark that area as valid.
`
`SAMPLE will display this text even when the program is minimized to be displayed as an
`icon at the bottom of the screen. Although most Windows programs use a customized icon
`for this purpose, the window—class structure in SAMPLE indicates that the program’s icon
`is NULL, meaning that the program is responsible for drawing its own icon. SAMPLE does
`not, however, make any special provisions for drawing the icon. To it, the icon is simply
`a small client area. As a result, SAMPLE displays the word Windows in its “icon,” using a
`small font size.
`
`Windows sends the window function the WM_DESTROY message as a result of the
`DestroyWindow function that Def WindowProc calls when processing a WM- CLOSE
`message. The standard processing involves placing a WM_QUIT message in the message
`queue:
`
`PostQuitMessage (0)
`
`;
`
`When the GetMessage function retrieves WM_QUIT from the message queue, GetMessage
`returns 0. This terminates the message loop and the program.
`
`528
`
`The MS-DOS Encyclopedia
`
`
`
`OLYMPUS EX. 1010 - 538/1582
`
`

`

`
`
`
`
`M_-..——
`
`Article 17: Windows
`
`’For all other messages, SAMPLE calls DefWindowProc and exits the window function by
`returning the value from the call:
`
`return DefWindowProc (hWnd,
`
`iMessage, wParam,
`
`lParam)
`
`;
`
`This allows Windows to perform default processing on the messages SAMPLE ignores.
`
`Windows’ multitasking
`
`Most operating systems or Operating environments that allow multitasking use what is
`called a preemptive scheduler. Generally, the procedure involves use of the computer’s
`clock to switch rapidly between programs and allow each a small time slice. When
`switching between progr