INFO: Developing Win32-Based GDI Apps for Windows 95 and Windows NT or Windows2000

ID: Q136989

This article discusses a Beta release of a Microsoft product. The information in this article is provided as-is and is subject to change without notice.

No formal product support is available from Microsoft for this Beta product. For information about obtaining support for a Beta release, please see the documentation included with the Beta product files, or check the Web location from which you downloaded the release.
The information in this article applies to:
  • Microsoft Win32 Application Programming Interface (API), used with:
    • Microsoft Windows 2000
    • Microsoft Windows NT, versions 3.51, 4.0

SUMMARY

When developing a Win32 application, you need to take certain programming aspects into consideration if the application is expected to be run under both Windows 95 and Windows NT or Windows 2000.

For example, Windows 95, like Windows 3.x, still uses a 16-bit world coordinate system, while Windows NT and Windows 2000 use a 32-bit coordinate system. In addition, Windows 95 does not support the GM_ADVANCED graphics mode option that Windows NT and Windows 2000 support. The GetVersionEx() function can be used to determine the platform under which your application is running.


MORE INFORMATION

Because the SetGraphicsMode() mode function only accepts GM_COMPATIBLE in Windows 95, functions like SetWorldTransform() or ModifyWorldTransform() cannot be called to set or modify the world transformation for the specified device context. Windows NT and Windows 2000 support this functionality. However, Windows 95 ensures that enhanced metafiles look the same in Windows 95 as they do in Windows NT and Windows 2000. This means that enhanced metafiles are assumed to be played in GM_ADVANCED mode. If you want your GDI graphical output to look the same in both Windows 95 and Windows NT or Windows 2000, it is recommended that you use GM_COMPATIBLE on both platforms. If you use GM_ADVANCED in Windows NT or Windows 2000 and GM_COMPATIBLE in Windows 95, for example, your rectangles would look different because a GM_COMPATIBLE system excludes bottom and rightmost edges when it draws rectangles, while a GM_ADVANCED system includes them. Also, the way rotated TrueType fonts are drawn differs.

If you pass 32-bit coordinates to GDI functions in Windows 95, the system truncates the upper 16 bits of the coordinates before actually performing the function. If you want to run under both Windows NT or Windows 2000 and Windows 95, then you need to keep this in mind. When using the Chord(), Pie(), Arc(), and RoundRect() functions under Windows 95, the sum of the coordinates sent to the functions cannot exceed 32K. Also, the sum of the left and right or top and bottom fields can not exceed 32K.

No matter what platform you are running, whether it is Windows 95, Windows NT, or Windows 2000, a win32-based application must still delete all GDI objects when they're not needed. Logical objects should be created and deleted as they are needed. This will ensure that adequate space is always available for logical GDI objects because Windows 95 places them in the local 16-bit GDI heap, which is limited to 64K. All regions should be deleted with DeleteObject(). In addition, all bitmaps, brushes, extended pens, fonts, regular pens, and palettes should be deleted with DeleteObject(). A metafile DC should be deleted with CloseMetaFile(), and a metafile should be deleted with DeleteMetaFile(). An enhanced metafile DC should be deleted with CloseEnhMetaFile() and an enhanced metafile should be deleted with DeleteEnhMetaFile(). A memory DC created with CreateCompatibleDC() should always be deleted with the DeleteDC() function, a DC created with CreateDC() should be deleted with DeleteDC(), and a DC obtained by GetDC() should be released with ReleaseDC(). Physical GDI objects exist in global memory, so they are not limited to the GDI 16-bit local heap.

Both Windows 95 and Windows NT or Windows 2000 free all GDI resources owned by a 32-bit process when that process terminates. Windows 95 also cleans up any GDI resources of 16-bit processes if it is marked as a 4.0 application. Windows 95 doesn't immediately clean up GDI resources for 16-bit applications marked with a version less than 4.0. The system waits until all 16-bit applications have finished running. Then all GDI resources allocated by previous 16-bit applications are cleaned up. In Windows 95, regions are allocated from the 32-bit heap, so they can be as large as available memory. This is a great step forward from Windows 3.x where regions were limited to 64K. However, the number of region handles cannot exceed 16K.

In Windows 95, if you try to delete a GDI drawing object while it is selected into a DC with DeleteObject(), the call to DeleteObject() succeeds, but the result of the call is a non-functioning GDI object. In Windows NT and Windows 2000, a call to DeleteObject() on a GDI object selected into a DC will fail. You should always clear the selection of a GDI object before calling DeleteObject() on it.

The Windows NT and Windows 2000 operating systems automatically track the origin of all window-managed DC's and adjust their brushes to maintain an alignment of patterns on the surface. Windows 95 doesn't support automatic tracking of the brush origin, so an application must call the following three functions to align a brush each time it paints using a patterned brush: 


   UnrealizeObject()
   SetBrushOrgEx()
   SelectObject()


When creating patterned brushes with either CreatePatternBrush() or CreateDIBPatternBrush(), Windows 95 doesn't support bitmaps or DIBs greater than 8 by 8 pixels. Windows NT and Windows 2000 do not have this limitation. When writing an application that must be run under both platforms, you need to use a bitmap or DIB that is 8 by 8 pixels or less.

Windows NT and Windows 2000 provide a wide variety of pens. There are some limitations on pens in Windows 95:
  • The ExtCreatePen() function only supports the PS_SOLID style for geometric lines.


  • The PS_USERSTYLE and PS_ALTERNATE styles are not supported.


  • Dashed or dotted pen styles like PS_DASH, for example, are not supported in wide lines.


The following pen styles for geometric lines are supported in paths only in Windows 95: 


   PS_ENDCAP_ROUND, PS_ENDCAP_SQUARE, PS_ENDCAP_FLAT, PS_JOIN_BEVEL,
   PS_JOIN_MITER, and PS_JOIN_ROUND


The ExtCreateRegion() function fails in Windows 95 if the transformation matrix is anything other than a scaling or translation of the region. This is because world transforms that involve either shearing or rotations are not supported in Windows 95.

The return value to GetDIBits() is also different in Windows 95 from Windows NT and Windows 2000 when the "lpvBits" parameter is NULL. In Windows 95, if the lpvBits parameter is NULL and GetDIBits successfully fills the BITMAPINFO structure, the return value is the total number of scan lines in the bitmap. In Windows NT and Windows 2000, If the lpvBits parameter is NULL and GetDIBits successfully fills the BITMAPINFO structure, the return value is non-zero.

Windows 95 only records the following functions in a path: 


   ExtTextOut      LineTo          MoveToEx        PolyBezier
   PolyBezierTo    Polygon         Polyline        PolylineTo
   PolyPolygon     PolyPolyline    TextOut


To find a complete list of functions supported in Windows 95 and Windows NT or Windows 2000, view the WIN32API.CSV file in the Lib directory of the Microsoft Visual C++ compiler or Win32 SDK.


REFERENCES

The Win32api.csv file in the Lib directory of the Microsoft Visual C++ compiler or Win32 SDK.

"Programmer's Guide to Microsoft Windows 95," Microsoft Press.

Additional query words: GDI windows 95 graphics compatguidediff

Keywords : kbgraphic kbGDI kbWinOS2000 kbSDKPlatform kbSDKWin32 GdiMisc kbGrpGDI
Version : winnt:3.51,4.0
Platform : winnt
Issue type : kbinfo


Last Reviewed: August 31, 1999
© 2000 Microsoft Corporation. All rights reserved. Terms of Use.