win98+vc6.0 绘图函数的整型值好象是16位的。

[jiajite]

我在做一个绘图的程序，看见MSDN中关于CDC的成员函数有以下限制：Note Under Windows 95, all screen coordinates are limited
to 16 bits. Therefore, an int passed to a CDC member
function must lie in the range –32768 to 32767。
在win98下有没有这个限制？win98的API和WIN95的API 是不是一样的
？

[jiajite]

我在win98下试过，还是有此限制，怎么办？

[xubin_sh]

windows 9x的有些GDI部件是16位的！

Platform SDK: Win32 API
Windows 95/98 Graphics Device Interface
Windows 95/98 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/98 uses a 16-bit world coordinate system and restricts x- and y- coordinates for text and graphics to the range ±32K. Windows NT/Windows 2000 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/98, the system truncates the upper 16 bits of the coordinates before carrying out the requested operation.

Because Windows 95/98 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/98 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/98 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/98 only supports the following color masks for 16 and 32 bits per pixel (bpp).

16bpp The blue mask is 0x001F, the green mask is 0x03E0, and the red mask is 0x7C00.
16bpp The blue mask is 0x001F, the green mask is 0x07E0, and the red mask is 0xF800.
32bpp The blue mask is 0x000000FF, the green mask is 0x0000FF00, and the red mask is 0x00FF0000.


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/98 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/98, 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.

PS_ENDCAP_FLAT
PS_ENDCAP_ROUND
PS_ENDCAP_SQUARE PS_JOIN_BEVEL
PS_JOIN_MITER
PS_JOIN_ROUND


Windows 95/98 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/98 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/98 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/98, 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.

Object Create with Delete with
Bitmap CreateBitmap, CreateBitmapIndirect, CreateCompatibleBitmap, CreateDIBitmap, CreateDIBSection, CreateDiscardableBitmap DeleteObject
Brush CreateBrushIndirect, CreateDIBPatternBrush, CreateDIBPatternBrushPt, CreateHatchBrush, CreatePatternBrush, CreateSolidBrush DeleteObject
Color space CreateColorSpace DeleteColorSpace
Device context (DC) CreateDC,
GetDC DeleteDC, ReleaseDC
Enhanced metafile CloseEnhMetaFile, CopyEnhMetaFile, GetEnhMetaFile, SetEnhMetaFileBits DeleteEnhMetaFile
Enhanced metafile DC CreateEnhMetaFile CloseEnhMetaFile
Extended pen ExtCreatePen DeleteObject
Font CreateFont, CreateFontIndirect DeleteObject
Memory DC CreateCompatibleDC DeleteDC
Metafile CloseMetaFile, CopyMetaFile,
GetMetaFile, SetMetaFileBitsEx DeleteMetaFile
Metafile DC CreateMetafile CloseMetaFile
Palette CreatePalette DeleteObject
Pen CreatePen, CreatePenIndirect DeleteObject
Region CombineRgn, CreateEllipticRgn, CreateEllipticRgnIndirect, CreatePolygonRgn, CreatePolyPolygonRgn, CreateRectRgn, CreateRectRgnIndirect, CreateRoundRectRgn, ExtCreateRegion, PathToRegion DeleteObject


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

Object Deletion
There are platform differences in the way drawing objects are deleted. In Windows NT/Windows 2000, if a drawing object (pen or brush) is deleted while it is still selected into a DC, the DeleteObject function fails. In Windows 95/98, 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/98, 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/98, the GetGraphicsMode and SetGraphicsMode functions support the GM_COMPATIBLE value only. The GM_ADVANCED value is not supported.

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

DC_DATATYPE_PRODUCED Retrieves an array of strings containing the data types that the printer driver supports. A return value of – 1 indicates that the printer driver only understands device-specific commands (in other words, "RAW" data) that are native to the printer. A return value of 2 or more indicates the number of strings in the array.
DC_EMF_COMPLIANT Returns a flag that indicates if the specified printer driver is capable of accepting an enhanced metafile (EMF) spooled by the system (that is, the printer driver is EMF-compliant). The function returns 1 if the printer driver is EMF-compliant and – 1 if the printer driver is not.


Enhanced Metafiles
Although Windows 95/98 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/98, 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/98, 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/98, however, does not support the the following members; they are included for compatibility with Windows NT/Windows 2000.

dmBitsPerPel
dmDisplayFlags
dmDisplayFrequency dmFormName
dmPelsHeight
dmPelsWidth


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

AddForm
AddPrinterConnection
ConnectToPrinterDlg
DeleteForm
DeletePrinterConnection
EnumForms
FindClosePrinterChangeNotification FindFirstPrinterChangeNotification
FindNextPrinterChangeNotification
GetForm
ResetPrinter
SetForm
WaitForPrinterChange


In Windows 95/98, 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/98. The PRINTER_INFO_5 structure, which is available in Windows 95/98, is not supported in versions of Windows NT earlier than version 4.0.

The PRINTER_ENUM_CONNECTIONS value used with the EnumPrinters function is not supported in Windows 95/98. 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/98 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/98, 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/Windows 2000, 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/98, lpszDeviceName must be NULL.

Built on Wednesday, March 29, 2000

[wangjiamin]

没有办法，想法升级系统吧，这个问题确实存在