Windows 95 Graphics Device Interface

Windows 95 implements some GDI features in 16 bits. The use of 16 bits imposes some restrictions on parameters in functions and places limits on internal storage.

Coordinate System

Windows 95 uses a 16-bit world coordinate system and restricts x- and y- coordinates for text and graphics to the range ±32K. Windows NT uses a 32-bit world coordinate system and allows coordinates in the range ±2 gigabytes (GB). If you pass full 32-bit coordinates to text and graphics functions in Windows 95, the system truncates the upper 16 bits of the coordinates before carrying out the requested operation.

Because Windows 95 uses a 16-bit coordinate system, the sum of the coordinates of the bounding rectangle specified by the Arc, Chord, Pie, Ellipse, and RoundRect functions cannot exceed 32K. In addition, the sum of the nLeftRect and nRightRect parameters or the nTopRect and nBottomRect parameters cannot exceed 32K.

World Transformations

Windows 95 does not support world transformations that involve either shearing or rotations. The ExtCreateRegion function fails if the transformation matrix is anything other than a scaling or translation of the region.

Bitmaps

Windows 95 does not support the CBM_CREATEDIB value for the CreateDIBitmap function. The CreateDIBSection function should be used instead to create a DIB. CreateDIBSection is also available in Windows NT version 3.5.

If the biCompression member of the BITMAPINFOHEADER structure is the BI_BITFIELDS value, the bmiColors member of the BITMAPINFO structure contains three doubleword color masks that specify the red, green, and blue components, respectively, of each pixel. Windows 95 only supports the following color masks for 16 and 32 bits per pixel (bpp).

If the lpvBits parameter is NULL, the GetDIBits function fills in the dimensions and format of the bitmap in the BITMAPINFO structure pointed to by the lpbi parameter. In this case, if the function is successful, the return value in Windows 95 is the total number of scan lines in the bitmap. In Windows NT versions 3.1 and 3.5, however, the return value is 1 (TRUE), indicating success.

Pens and Brushes

In Windows 95, pens and brushes have several limitations. The ExtCreatePen function supports solid colors only (the PS_SOLID style), and the PS_ALTERNATE and PS_USERSTYLE styles are not supported. Geometric pens (the PS_GEOMETRIC style) are limited to the BS_SOLID brush style specified in the LOGBRUSH structure passed to ExtCreatePen. In addition, the following pen styles are supported in paths only.

Windows 95 does not support the dashed or dotted pen styles, such as PS_DASH or PS_DOT, in wide lines. The BS_DIBPATTERN brush style is limited to an 8- by 8-pixel brush.

Windows 95 does not support brushes from bitmaps or device independent bitmaps (DIBs) that are larger than 8 by 8 pixels. Although bitmaps larger than 8 by 8 pixels can be passed to the CreatePatternBrush or CreateDIBPatternBrush function, only a portion of the bitmap is used to create the brush.

Windows 95 does not provide automatic tracking of the brush origin. An application is responsible for using the UnrealizeObject, SetBrushOrgEx, and SelectObject functions each time it paints using a pattern brush.

Logical Objects

In Windows 95, regions are allocated from the 32-bit heap and can, therefore, be as large as available memory. All other logical objects, however, share the 64K local heap. In addition, the number of region handles cannot exceed 16K.

To ensure that adequate space is always available for logical objects, applications should always delete objects when no longer needed. The following functions create objects that are placed in the local heap and have corresponding functions used to delete the objects.

Physical objects have always existed in global memory and are, therefore, not limited.

Object Deletion

Deletion of drawing objects is slightly different in Windows 95 than in Windows NT. In Windows NT, if a drawing object (pen or brush) is deleted while it is still selected into a DC, the DeleteObject function fails. In Windows 95, the function succeeds, but the result is a nonfunctioning object. This nonfunctioning object is automatically destroyed when the DC is deleted.

Paths

When a path is constructed in Windows 95, only the following functions are recorded: ExtTextOut, LineTo, MoveToEx, PolyBezier, PolyBezierTo, Polygon, Polyline, PolylineTo, PolyPolygon, PolyPolyline, and TextOut.

Graphics Mode and Device Capabilities

In Windows 95, the GetGraphicsMode and SetGraphicsMode functions support the GM_COMPATIBLE value only. The GM_ADVANCED value is not supported.

In Windows 95, the DeviceCapabilities function returns – 1 when called with the DC_FILEDEPENDENCIES value because that capability is not supported. In Windows 95, DeviceCapabilities supports the following additional capabilities.

Enhanced Metafiles

Although Windows 95 imposes no restrictions on the PlayEnhMetaFile and PlayEnhMetaFileRecord functions, the files and records that these functions execute are subject to the limitations described in this section. For example, the functions ignore records that attempt to draw outside of the 16-bit coordinate space or that apply shearing or rotation to world transformations.

In Windows 95, the maximum length of the description string for an enhanced metafile is 16K. This limit applies to the GetEnhMetaFileDescription, GetEnhMetaFileHeader, and GetEnhMetaFile functions.

In Windows 95, the dmDeviceName member of the DEVMODE structure specifies the "friendly" name of the printer, which may be set to any user-defined value. Windows 95, however, does not support the the following members; they are included for compatibility with Windows NT.

Printing and Print Spooler

Windows 95 does not support print monitor dynamic-link libraries (DLLs) that have been developed for Windows NT. To add a monitor using the AddMonitor function, you must specify a monitor DLL that has been explicitly created for Windows 95. The following printing and print spooling functions are not available in Windows 95.

In Windows 95, the SetPrinter function ignores the pShareName member of the PRINTER_INFO_2 structure. The PRINTER_INFO_3 and PRINTER_INFO_4 structures used with the SetPrinter, GetPrinter, and EnumPrinters functions are not supported in Windows 95. The PRINTER_INFO_5 structure, which is available in Windows 95, is not supported in Windows NT versions 3.1 and 3.5.

The PRINTER_ENUM_CONNECTIONS value used with the EnumPrinters function is not supported in Windows 95. The DOC_INFO_2 structure used with the StartDocPrinter function and the PORT_INFO_2 structure used with the EnumPorts function are not supported in Windows NT versions 3.1 and 3.5.

Windows 95 supports the DRAWPATTERNRECT printer escape.

Win32-based applications that send output to PostScript™ printers should use the GetDeviceCaps function to check for the PC_PATHS value to determine whether to use path functions or printer escapes to draw paths. Applications should use paths functions whenever possible. The following example shows how to check for this capability.

// Determine whether to use path functions on the device.
// hDC is the output device. 

OSVERSIONINFO osvi;

osvi.dwOSVersionInfoSize = sizeof(osvi);
GetVersionEx(&osvi);

if ((osvi.dwPlatformId == VER_PLATFORM_WIN32_NT) || 
     ((osvi.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS) && 
       (GetDeviceCaps(hDC, POLYCAPS) & PC_PATHS)))
    bUsePaths = TRUE;
else
    bUsePaths = FALSE;
 

In Windows 95, printer drivers typically set this capability to zero. This means that Win32-based applications sending output to Postscript printers need to use the ExtEscape function and the printer-specific escapes to draw paths at the printer. (The Escape function cannot be used for this.)

In Windows NT, the string specified in the lpszDeviceName parameter of the EnumDisplaySettings function must be of the form "\\.\DisplayX", where X can be 1, 2, or 3. In Windows 95, lpszDeviceName must be NULL.