PRB: Inconsistencies in GDI APIs Between Win32s and Windows NT

• 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.

  -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.