PSS ID Number: 123421
Article Last Modified on 1/20/2000
The information in this article applies to:
This article was previously published under Q123421
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.
-or-
- 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: KB123421
Technology: kbWin32s120 kbWin32sSearch