I have a .Net application that during handling of WM_NCPAINT for one of its windows
genarates exception "Arithmetic operation resulted in an overflow.". This happens
only in a 64-bit prefix and only for WPARAM that contains an HRGN handle with value
over than 0x7fffffff.
The application does the following:
public static IntPtr GetNativeDC(Message m, IntPtr handle)
{
if (m.Msg != 0x85) // WM_NCPAINT
{
return NUser32.GetWindowDC(handle);
}
int num = 0x200013; // DCX_VALIDATE | DCX_CLIPSIBLINGS | DCX_CACHE | DCX_WINDOW
IntPtr intPtr = IntPtr.Zero;
IntPtr wParam = m.WParam;
if (wParam.ToInt32() != 1)
{
num |= 0x80; // DCX_INTERSECTRGN
intPtr = CreateRectRgn(0, 0, 1, 1);
CombineRgn(intPtr, wParam, IntPtr.Zero, 5); // RGN_COPY
}
return NUser32.GetDCEx(handle, intPtr, num);
}
The exception is generated by wParam.ToInt32(). MSDN description for ToInt32()
https://learn.microsoft.com/en-us/dotnet/api/system.intptr.toint32?view=net…
states
Exceptions
OverflowException
In a 64-bit process, the value of this instance is too large or too small
to represent as a 32-bit signed integer.
MSDN also has a reference to ToInt32() source:
https://github.com/dotnet/runtime/blob/5535e31a712343a63f5d7d796cd874e563e5…
public int ToInt32()
{
#if TARGET_64BIT
return checked((int)_value);
#else
return (int)_value;
#endif
}
It's not clear why a sign extension may lead to an overflow exception.
This patch fixes the problem, and provides a test case that confirms that
entry.Generation field of a GDI32 object is limited by 127 on a 64-bit
platform, while 32-bit Windows doesn't have such a limitation.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5777
Previously, PSDRV_ResetDC() only updated the devmode contained in the
print context, which could cause the devmode in the unix interface to be
inconsistent with the print context's devmode. This can cause problems
later when PostScript is being outputted, as get_device_caps() in the
unix interface would reference this inconsistent devmode. By calling
ResetDCW() in PSDRV_ResetDC(), these two devmodes remain in-sync.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5778
On Mon Jun 3 16:19:12 2024 +0000, Vibhav Pant wrote:
> I'm sorry, what are the "earlier patches" in this context? Also, I was
> not entirely sure what the component modified would be, as both
> NtCreationSection and CreateFileMapping would be affected by the patch,
> which are in different components. Would wineserver be appropriate?
Your MR at each moment should be the set of finalized patches. If you are changing something in existing patches you update / replace those without adding new patches. You set the component which your patch is directly modifying. If there is more than one (rare occasion which often means you need to split your patches) you specify higher level component. I'd really suggest to view some commit history for the related components for examples.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5769#note_72236