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.
--
v2: win32u: Limit GDI object generation by 128.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5777
[test_WaitForInputIdle.tar.bz2](/uploads/a20c5b119741cd7b0b4813488854a992/test_WaitForInputIdle.tar.bz2)
Attached test replicates the problem. Basically the application does
process = OpenProcess(SYNCHRONIZE | PROCESS_QUERY_INFORMATION, FALSE, GetCurrentProcessId());
ret = WaitForInputIdle(process, 0x7fffffff);
assert(ret == 0);
With current wine.git WaitForInputIdle() returns WAIT_FAILED because the server call
get_process_idle_event() refuses to return idle_event for the current process. If that
limitation is removed then wineserver crashes, and other parts of the patch fix the crash.
--
v2: server: Remove limitation for waiting on idle_event of the current process.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5789
Instead of accessing the surface with macdrv_get_surface_display_image.
--
v2: winemac: Remove now unnecessary cocoa window surface pointer.
winemac: Push window surface image updates to the main thread.
winemac: Create window surface CGImageRef on surface flush.
winemac: Create a provider for the surface and a HBITMAP wrapping it.
winemac: Remove unused macdrv_get_surface_display_image copy_data parameter.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5798
This is an early draft of an implementation of key auto-repeat in wineserver to get some feedback. Some open questions:
1. queue_keyboard_message requires a `current` thread, but we don't get one in timeout callbacks. At the moment I am manually setting `current` to the foreground thread, but I am wondering if that's acceptable or we should explore other ways forward (also see TODO in code).
2. This draft introduces a new server request to configure auto-repeat (`enable/delay/period`). I am thinking that for more straightforward integration with the keyboard repeat SPI parameters, the request should only support the `enable` flag and the server should query the SPI registry values to get `delay` and `period` when needed. I am wondering if there any caveats here since I don't see other code in the server querying registry values (well, except to implement the registry requests themselves).
Also, I would hope that opening and caching the `HKCU\Control Panel\Keyboard` hkey would remove most of the cost of performing this operation (if that's even a concern at all).
--
v5: win32u: Implement keyboard auto-repeat using new server request.
server: Implement key auto-repeat request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5741
This is an early draft of an implementation of key auto-repeat in wineserver to get some feedback. Some open questions:
1. queue_keyboard_message requires a `current` thread, but we don't get one in timeout callbacks. At the moment I am manually setting `current` to the foreground thread, but I am wondering if that's acceptable or we should explore other ways forward (also see TODO in code).
2. This draft introduces a new server request to configure auto-repeat (`enable/delay/period`). I am thinking that for more straightforward integration with the keyboard repeat SPI parameters, the request should only support the `enable` flag and the server should query the SPI registry values to get `delay` and `period` when needed. I am wondering if there any caveats here since I don't see other code in the server querying registry values (well, except to implement the registry requests themselves).
Also, I would hope that opening and caching the `HKCU\Control Panel\Keyboard` hkey would remove most of the cost of performing this operation (if that's even a concern at all).
--
v6: win32u: Implement keyboard auto-repeat using new server request.
server: Implement key auto-repeat request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5741
--
v3: win32u: Pass the rect DPI to NtUserIsWindowRectFullScreen.
win32u: Introduce a new get_monitor_rect helper.
win32u: Pass desired DPI to NtUserGet(Client|Window)Rect.
win32u: Introduce NtUserAdjustWindowRect call for AdjustWindowRect*.
win32u: Introduce new helpers to convert server rectangle_t.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5776