Microsoft KB Archive/123421

{|
 * width="100%"|

PRB: Inconsistencies in GDI APIs Between Win32s and Windows NT

 * }

Q123421

-

The information in this article applies to:


 * Microsoft Win32s version 1.2

-

SYMPTOMS
The StretchBlt and StretchDIBits/SetDIBits GDI APIs do not behave consistently under Win32s and Windows NT.

StretchBlt
If the source width and height specified in the call to StretchBlt are greater than the actual bitmap width and height, StretchBlt fails. The same call to StretchBlt succeeds under Windows NT.

StretchDIBits/SetDIBits
If the memory pointed to by the lpBits parameter is read-only, the call to StretchDIBits/SetDIBits fails.

NOTE: When a Win32-based application uses the memory returned from LockResource as a parameter to SetDIBits, by default, it's using read-only memory, because the resource section is defined by default as read-only.

CAUSE
These problems are due to bugs in Windows. In the case of StretchDIBits and SetDIBits, Windows mistakenly verifies that the buffer is writable. This problem does not show up in a 16-bit Windows-based application running under Windows because resources are loaded into read/write (global) memory.

RESOLUTION
In Win32s version 1.25, Win32s will always make the resource section read/write, regardless of what is specified in the section attributes. This will work around the problem. In the meantime, use the following resolutions:

StretchBlt
To work around the problem, specify the proper width and height for the source bitmap.

StretchDIBits/SetDIBits
To work around the problem, do one of the following:


 * Copy the memory to a temporary read/write buffer.
 * Use the linker switch /SECTION:.rsrc,rw to make the resource section read/write. Windows NT will allocate separate resource sections for each copy of the application.

Additional query words: 1.20

Keywords :

Issue type :

Technology : kbWin32sSearch kbWin32s120