PAINTSTRUCT is not defined properly

[JeremyKuhne]

PAINTSTRUCT is currently being generated as:

internal partial struct PAINTSTRUCT
{
	internal winmdroot.Graphics.Gdi.HDC hdc;
	internal winmdroot.Foundation.BOOL fErase;
	internal winmdroot.Foundation.RECT rcPaint;
	internal winmdroot.Foundation.BOOL fRestore;
	internal winmdroot.Foundation.BOOL fIncUpdate;
	internal unsafe byte* rgbReserved;
}

The final field is actually a fixed array:

BYTE rgbReserved[32];

[JeremyKuhne]

cc: @AaronRobinsonMSFT

[JeremyKuhne]

Note that this only causes failures running as a 32bit process on a 64bit OS. The BeginPaint implementation doesn't reference the final field, but the WOW layer does.

[AaronRobinsonMSFT]

It is fine to clarify a particular scenario is heavily impacted by this incorrect definition, but it doesn't change the definition is incorrect. It is possible to create a GC hole via heap corruption, that means it is suspect. This definition and any similar patterns should be scrutinized heavily because end-users are far less likely to have the experience to track down the problem this type of definition can cause.

[JeremyKuhne]

It is fine to clarify a particular scenario is heavily impacted by this incorrect definition, but it doesn't change the definition is incorrect.

The point was to clarify a way these can get missed for a commonly used API. One would suspect that the majority of users are running as 64bit. It was not an attempt to lower the priority. :)

[elachlan]

Won't this be in the metadata https://github.com/microsoft/win32metadata?

[elachlan]

related issue: microsoft/win32metadata#215

[elachlan]

This is the underlying generated code for the rgbReserved field: internal __byte_32 rgbReserved;

[AArnott]

CsWin32 gets this right when allowMarshaling=true. So this is unique to allowMarshaling=false. This seems really similar to #597, so I'm surprised fixing that didn't fix this. I'll try to look into this by early next week. Or @elachlan, as you have been great at investigating these so far, you're welcome to grab it.

[AaronRobinsonMSFT]

Note that this only causes failures running as a 32bit process on a 64bit OS.

I am seeing this when running as a 64-bit process too.

[JeremyKuhne]

I am seeing this when running as a 64-bit process too.

Yeah, I was looking at the wrong endpoint. BeginPaint is actually NtUserBeginPaint, which always does a copy. I suspect we're not seeing runtime failures on x64 due to padding/alignment.

[JeremyKuhne]

@AArnott we're out of date here- we are using 0.2.1, so this is probably fixed. Validating.

[JeremyKuhne]

Yes, updating to 0.2.10 fixes the problem. Sorry for the noise!