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

• Microsoft Win32 Software Development Kit (SDK) 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.

For example, Windows 95, like Windows 3.x, still uses a 16-bit world coordinate system, while Windows NT uses a 32-bit coordinate system. In addition, Windows 95 does not support the GM_ADVANCED graphics mode option that Windows NT supports. 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 supports this functionality. However, Windows 95 ensures that enhanced metafiles look the same in Windows 95 as they do in Windows NT. 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, it is recommended that you use GM_COMPATIBLE on both platforms. If you use GM_ADVANCED in Windows NT 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 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 or Windows NT, 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 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, 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 operating system automatically tracks the origin of all window-managed DC's and adjusts 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()

Windows NT provides 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.

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

The return value to GetDIBits() is also different in Windows 95 from Windows NT 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, 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

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.