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(cid:173)
`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.
`SAMPLE.RC, 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", IDM_SCRIPT, CHECKED
`MENUITEM "&Modern",
`IDM_MODERN
`MENUITEM "&Roman",
`IDM_ROMAN
`
`END
`
`END
`
`Figure 17-12. The resource script for the SAMPLE program.
`
`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(cid:173)
`gram source-code file. For example, in the SAMPLE.RC resource script, each item in
`the pop-up menu (Script, Modern, and Roman) also includes an identifier(cid:173)
`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(cid:173)
`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, SAMPLE.H, is shown in Figure 17-13.
`
`#define IDM_SCRIPT 1
`#define IDM-MODERN 2
`#define IDM_ROMAN
`3
`
`Figure 17-13. The SAMPLE.H header file.
`
`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(cid:173)
`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(cid:173)
`grams that are divided into multiple code segments, the module-definition file allows
`the programmer to specify different attributes for each code segment.
`
`516
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 526/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 -Zdp sample.c
`
`-
`
`This step uses the CL.EXE C compiler to create a .OBJ object-module file. The com(cid:173)
`mand line switches are
`-c: Compiles the program but does not link it. Windows programs must be linked ·
`-
`with Windows' LINK4linker, rather than with the LINK program the C compiler
`would normally invoke.
`-Gsw: Includes two switches, -Gs 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(cid:173)
`dows' memory management.
`-W2: Compiles with warning level2. 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.
`-Zdp: Includes two switches, -Zd and -Zp. The -Zd switch includes line numbers
`in the .OBJ 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.
`2. Compiling the resource script:
`
`-
`
`rc -r sample.rc
`
`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.
`3. 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 .OBJ 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.
`4. Adding the resources to the .EXE file:
`
`rc sample.res
`
`518
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 528/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 SAMPLE.C program shown in Figure 17-11 contains some code that appears in almbst
`every Windows program. The statement
`
`#include <windows.h>
`
`appears at the top of every Windows source-code file written in C. The WINDOWS.H 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 SAMPLE.C 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
`
`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 (hlnstance), a handle to the most recent previous instance of the program
`(hPrevlnstance), a long pointer to the program's command line (lpszCmdLine), 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 lpfnWndProc).
`
`520
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 530/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(cid:173)
`gram can adjust its screen output to fit the new window size. Thus, for example, if a Win(cid:173)
`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(cid:173)
`ticular window in a particular instance of a Windows program. Windows therefore deter(cid:173)
`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 (GetMessage (&msg, NULL, 0, ,0))
`(
`TranslateMessage (&msg)
`DispatchMessage (&msg)
`)
`
`;
`
`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
`
`HUAWEI EX. 1010 - 532/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
`WINDOWS.H header file includes identifiersJor 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 wParam and lParam parameters are discussed here:
`
`WM_CREATE. Windows sends a window function this nonqueued message while pro(cid:173)
`cessing the CreateWindow call. The lParam parameter is a pointer to a creation structure.
`A window function can perform some program initialization during the WM_ CREATE .
`message.
`
`WM_MOVE. Windows sends a window function the nonqueued WM_MOVE message
`when the window has been moved to another part of the display. The lParam parameter
`gives the new coordinates of the window relative to the upper left corner of the screen.
`
`WM_SIZE. This nonqueued message indicates that the size of the window has been
`changed. The new size is encoded in the lParam 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.
`
`WM_KEYDOWN. The wParam parameter of this queued message is a virtual key code
`that identifies the key being pressed. The lParam 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 wParam parameter is a virtual key code.
`
`WM_CHAR. This queued message is generated from WM_KEYDOWN messages during
`the TranslateMessage call. The wParam parameter is the ASCII code of a keyboard key.
`
`WM_MOUSEMOVE. Windows uses this queued message to tell a program about mouse
`movement. The lParam parameter contains the coordinates of the mouse relative to the
`upper left corner of the client area of the window. The wParam parameter contains flags
`that indicate whether any mouse buttons or the Shift or Ctrl keys are currently pressed.
`
`WM_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 wParam and lParam parameters are
`the same as for WM_MOUSEMOVE.
`
`524
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 534/1582
`
`

`

`

`

`Part D: Directions of MS-DOS
`
`(nonclient paint) message. The window function normally passes this message to
`DefWindowProc, 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(cid:173)
`dows session when the user selects the Close option from its system menu, then applica(cid:173)
`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(cid:173)
`rently running application. If any application responds by returning a zero value, the MS(cid:173)
`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(cid:173)
`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, DefWindowProc 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, DefWindowProc 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 Send Message 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, OL)
`
`;
`
`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
`
`HUAWEI EX. 1010 - 536/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 I 8,
`0, O, 400, 0, 0, 0, OEM_CHARSET,
`OUT_STROKE_pRECIS, OUT_STROKE_pRECIS,
`DRAFT-QUALITY,
`(BYTE) VARIABLE_piTCH
`cFamily [nCurrentFont- IDM___SCRIPT],
`szFace
`[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)
`
`;
`
`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(cid:173)
`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 DefWindowProc 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
`
`HUAWEI EX. 1010 - 538/1582
`
`

`

`

`

`Part D: Directions of MS-DOS
`
`The device context (DC)
`When a Windows program needs to send output to the video screen, the printer, or
`another graphics output device, it must first obtain a handle to the device's device context,
`or DC. Windows provides a number of functions for obtaining this device-context handle:
`
`Begin Paint. Used for obtaining a video device-context handle during processing of a
`WM_PAINT message. This device context applies only to the rectangular section of the
`client area that is invalid (needs repainting). This region is also a clipping region, meaning
`that a program cannot paint outside this rectangle. BeginPaint fills in the fields of a
`PAINTSTRUCT structure. This structure contains the coordinates of the invalid rectangle
`and a byte that indicates if the background of the invalid rectangle has been erased.
`
`GetDC. Generally used for obtaining a video device-context handle during processing of
`messages other than WM_PAINT. The handle obtained with this function references only
`the client area of the window.
`
`GetWindowDC. Used for obtaining a video device-context handle that encompasses the
`entire window, including the title bar, menu bar, and scroll bars. A Windows program can
`use this function if it is necessary to paint over areas of the window outside the client area.
`
`CreateDC. Used for obtaining a device-context handle for the entire display or for a
`printer, a plotter, or other graphics output device.
`
`Create/C. Used for obtaining an information-context handle, which is similar to a
`device-context handle but can be used only for obtaining information about the output
`device, not for drawing.
`
`CreateCompatibleDC. Used for obtaining a device-context handle to a memory device
`context compatible with a particular graphics output device. This function is generally
`used for transferring bitmaps to a graphics output device.
`
`CreateMetaFile. Used for obtaining a metafile device-context handle. A metafile is a collec(cid:173)
`tion of GDI calls encoded in binary form.
`
`The Windows program uses the device-context handle when calling GDI functions. In
`addition to drawing, the various GDI functions can change the attributes of the device con(cid:173)
`text, select different drawing objects (such as pens and fonts) into the device context, and
`determine the characteristics of the device context.
`Device-independent programming
`Windows supports such a wide variety of video displays, printers, and plotters that pro(cid:173)
`grams cannot make assumptions about the size and resolution of the device. Furthermore,
`because the user can generally alter the size of a program's window, the program must be
`able to adjust its output appropriately. The SAMPLE program, for example, showed how
`the window function can use the WM_SIZE message to obtain the current size of a win(cid:173)
`dow to create a font that fits text within the window's client area.
`
`Programs can also use other Windows functions to determine the physical characteristics
`of a device. For instance, a program can use the GetDeviceCaps function to obtain
`
`530
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 540/1582
`
`

`

`Article 17: Windows
`
`information aboutthe device context, including the resolution of the device, its physical
`dimensions, and its relative pixel height and width.
`
`Then, too, the GetTextMetrics function returns information about the current font selected
`in the device context. In the default device context, this is the system font. Many Windows
`programs base the size of their display output on the size of a system-font character.
`Device-context attributes
`The device context includes attributes that define how the graphics output functions work
`on the device. When a program first obtains a handle to a device context, Windows sets
`these attributes to default values, but the program can change them. Some of these
`device-context attributes are as follows:
`
`Pen. Windows uses the current pen for drawing lines. The default pen produces a solid
`black line 1 pixel wide. A program can change the pen color, change to a dotted or dashed
`line, or make the pen draw a solid line wider than 1 pixel.
`
`Brush. Windows uses the current brush (sometimes called a pattern) for filling areas. A
`brush is an 8-pixel-by-8-pixel bitmap. The default brush is solid white. Programs can
`create colored brushes, hatched brushes, and customized brushes based on bitmaps.
`
`Background color. Windows uses the background color to fill the spaces in and between
`
`characters when drawing text and to color the open areas in hatched brushstrokes and 4
`
`dotted or dashed pen lines. Windows uses the background color only if the background
`mode (another attribute of the display context) is opaque. If the background mode is
`transparent, Windows leaves the background unaltered. The default background color
`is white.
`
`Text color. Windows uses this color for drawing text. The default is black.
`
`Font. Windows uses the font to determine the shape of text characters. The default is
`called the system font, a fixed-pitch font that also appears in menus, caption bars, and
`dialog boxes.
`
`Additional device-context attributes (such as mapping modes) are described in the follow(cid:173)
`ing sections.
`Mapping modes
`Most GDI drawing functions in Windows have parameters that specify the coordinates or
`size of an object. For instance, the Rectangle function has five parameters:
`
`Rectangle lhDC, x1, y1, x2, y2)
`
`;
`
`The first parameter is the handle to the device context. The others are
`
`•
`•
`•
`•
`
`xl: horizontal coordinate of the upper left corner of the rectangle.
`yl: vertical coordinate of the upper left corner of the rectangle.
`x2: horizontal coordinate of the lower right corner of the rectangle.
`y2: vertical coordinate of the lower right corner of the rectangle.
`
`Section JL- Programming in the MS-DOS Environment
`
`531
`
`HUAWEI EX. 1010 - 541/1582
`
`

`

`Part D: Directions <;>f MS-DOS
`
`In the Rectangle and most other GDI functions, coordinates are logical coordinates, which
`are not necessarily the same as the physical coordinates (pixels) of the device. To translate
`logical coordinates into physical coordinates, Windows uses the current mapping mode.
`
`In actuality, the mapping mode defines a transformation of coordinates between a win(cid:173)
`dow, which is defined in terms of logical coordinates, and a viewport, which is defined in
`terms of physical coordinates. For any mapping mode, a program can define separate win(cid:173)
`dow and viewport origins. The logical point defined as the window origin is then mapped
`to the physical point defined as the viewport origin. For some mapping modes, a program
`can also define window and viewport extents, which determine how the logical coordi(cid:173)
`nates are scaled to the physical coordinates.
`
`Windows programs can select one of eight mapping modes. The first six are sometimes
`called fully constrained, because the ratio between the window and viewport extents is
`fixed and cannot be changed.
`
`In MM_ TEXT, the default mapping mode, coordinates on the x axis increase from left to
`right, and coordinates on the y axis increase from the top downward. In the other five fully
`constrained mapping modes, coordinates on the x axis also increase from left to right, but
`coordinates on the y axis increase from the bottom upward. The six fully constrained
`mapping modes are
`
`• MM_TEXT: Logical coordinates are the same as physical coordinates.
`• MM_LOMETRIC: Logical coordinates are in units of 0.1 millimeter.
`• MM_HIMETRIC: Logical coordinates are in units of 0.01 millimeter.
`• MM_LOENGLISH: Logical coordinates are in units of 0.01 inch.
`• MM_HIENGLISH: Logical coordinates are in units of 0.001 inch.
`• MM_TWIPS: Logical coordinates are in units ofl/I44o inch. (These units are lho of a
`typographic point, which is approximately lfn inch.)
`
`The seventh mapping mode is called partially constrained, because a program can change
`the window and viewport extents but Windows adjusts the values to ensure that equal
`horizontal and vertical logical coordinates translate to equal horizontal and vertical physical
`dimensions:
`
`• MM_ISOTROPIC: Logical coordinates represent the same physical distance on both
`the x andy axes.
`
`The MM_ISOTROPIC mapping mode is useful for drawing circles and squares. The
`MM_LOMETRIC, MM_HIMETRIC, MM_LOENGLISH, MM_HIENGLISH, and
`MM_ TWIPS mapping modes are also isotropic, because equal logical coordinates map to
`the same physical dimensions on both axes.
`
`The final mapping mode is sometimes called unconstrained because a program is free to
`set different window and viewport extents on the x andy axes.
`
`• MM_ANISOTROPIC: Logical coordinates are mapped to arbitrarily scaled physical
`coordinates.
`
`532
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 542/1582
`
`

`

`

`

`Part D: Directions of MS-DOS
`
`Raster operations for pens
`When Windows uses a pen to write to a device context, it must first determine which pix(cid:173)
`els of the destination are to be altered by the pen (the foreground) and which pixels will
`not be affected (the background). With dotted and dashed pens, the background-
`the space between the dots or dashes- is left unaltered if the drawing mode is trans(cid:173)
`parent and is filled with the background color ifthe drawing mode is opaque.
`
`When Windows alters the pixels of the destination that correspond to the foreground of
`the pen, the most obvious result is that the color of the current pen defined in the display
`context is used to color the destination. But this is not the only possible result. Windows
`also generalizes the process by using a logical operation to combine the pixels of the pen
`and the pixels of the destination.
`
`This logical operation is defined by the drawing mode attribute of the device context. This
`drawing mode can be set to one of 16 binary raster operations (abbreviated ROP2).
`
`The following table shows the 16 binary raster operation codes defined in WINDOWS.H.
`The column headed "Resultant Destination" shows how the destination changes, depend(cid:173)
`ing on the bit pattern of the pen and the bit pattern of the destination before the line is
`drawn. The words OR, AND, XOR, and NOT are the logical operations.
`
`Binary Raster
`Operation
`
`Resultant
`Destination
`
`R2_BLACK
`R2_COPYPEN
`R2_MERGEPEN
`R2_MASKPEN
`R2_XORPEN
`R2_NOTCOPYPEN
`R2_NOTMERGEPEN
`R2_NOTMASKPEN
`R2_NOTXORPEN
`R2_MERGEPENNOT
`R2_MASKPENNOT
`R2_MERGENOTPEN
`R2_MASKNOTPEN
`R2_NOP
`R2_NOT
`R2_WHITE
`
`0
`pen
`pen OR destination
`pen AND destination
`pen XOR destination
`NOT pen
`NOT (pen OR destination)
`NOT (pen AND destination)
`NOT (pen XOR destination)
`pen OR (NOT destination)
`pen AND (NOT destination)
`(NOT pen) OR destination
`(NOT pen) AND destination
`destination
`NOT destination
`1
`
`The default drawing mode defined in a device context is R2_COPYPEN, which simply
`copies the pen to the destination. However, if the pen color is blue, the destination is red,
`and the drawing mode is R2_MERGEPEN, then the drawn line appears as magenta, which
`
`534
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 544/1582
`
`

`

`

`

`Part D: Directions of MS-DOS
`
`Raster
`Operation
`
`SRCINVERT
`SRCERASE
`MERGEPAINT
`NOTSRCCOPY
`NOTSRCERASE
`DSTINVERT
`PA,TCOPY
`MERGE COPY
`PATINVERT
`PATPAINT
`WHITENESS
`
`Resultant
`Destination
`
`source XOR destination
`source AND (NOT destination)
`source OR (NOT destination)
`NOT source
`NOT (source OR destination)
`NOT destination
`pattern
`source AND pattern
`destination XOR pattern
`source OR (NOT destination) OR pattern
`1
`
`The PatBlt function is similar to BitBlt and StretchBlt but performs a logical operation only
`between the currently selected brush and a destination area of the device context. Thus,
`only 16 raster operations can be used with PatBlt; these are equivalent to the binary raster
`operations used with line drawing.
`Text and fonts
`Windows supports file-based text fonts in two different formats: raster and vector. The
`raster fonts, such as Courier, Helvetica, and Times Roman, are defined by digital represen(cid:173)
`tations of the bit patterns of the characters. Font files usually contain several different sizes
`for each typeface. The vector fonts, such as Modern, Script, and Roman, are defined by
`points that are connected to form the letters and can be scaled to different sizes.
`
`When using a device such as a printer, which has built-in fonts, Windows can also use
`these device-based fonts.
`
`To specify a font, a Windows program uses the CreateFont function to create a logical
`font- a detailed description of the desired font. When this logical font is selected into a
`device context, Windows finds the actual font that best fits this description. In many cases,
`this match is not exact. The program can then call GetTextMetrics to determine the char(cid:173)
`acteristics of the actual font that the device will use to display text.
`
`Windows supports both fixed-width and variable-width fonts, as well as such attributes as
`italics, underlining, and boldfacing. Programs can also justify text with the GetTextExtent
`call, which obtains the width of a particular text string. The program can then insert extra
`spaces between words with SetTextJustification or it can insert extra spaces between
`letters with SetTextCharacterExtra.
`Metafiles
`As explained earlier, a metafile is a collection of GDI function calls stored in a binary
`coded form. A program can create a metafile by calling CreateMetaFile and giving it either
`
`536
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 546/1582
`
`

`

`

`

`Part D: Directions of MS-DOS
`
`• Metafile Picture: A structure that contains a handle to a metafile al