On Wed Aug 2 20:04:56 2023 +0000, Bernhard Kölbl wrote:
> Since no one answered, yet:
> 1. IIRC we don't want ReactOS code in Wine, as it might be reverse engineered.
> 2. This very likely needs tests.
I wrote the functions in question here first; and also put up a PR over there with a modified version of it.
I can think about some tests.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3360#note_41123
1. Subtracting integers may result in an overflow or underflow.
2. Right at the 'edge' of underflowing, the result of subtraction may be
`INT_MIN`, and the call to `abs()` will also result in `INT_MIN`.
This fix accounts for all of these conditions.
EXAMPLES:
1. can be encountered by comparing 2.0 and -2.0
2. can be encountered by comparing -2.0 and 2.0
NOTE:
There are 14 more instances of `compare_float` across several modules.
I would like to make sure the logic is sound with this MR, then I can take on the rest.
--
v4: ddraw/tests: Use compare_uint() in compare_float() instead of abs().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3458
On Wed Aug 2 20:04:56 2023 +0000, Huw Campbell wrote:
> I had a review from the ReactOS guys with some suggestions, but before I
> make them is there any interest in taking up maintenance changes like
> the for the shell?
> Who should I ping for a review?
Since no one answered, yet:
1. IIRC we don't want ReactOS code in Wine, as it might be reverse engineered.
2. This very likely needs tests.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3360#note_41115
Today, if media_source_Shutdown is called around the same time
as a work item is put on the async_commands_queue, we end up in
a deadlock if Shutdown enters media source's cs first, as it
waits for the queue's callback to finish, which, in turn,
waits for the object's cs to be released.
To avoid this leave the cs, before unlocking the workqueue,
to let any callback on the queue finish running.
Signed-off-by: Bernhard Kölbl <bkoelbl(a)codeweavers.com>
Blocks !3351
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3491
I expect this is going to be tricky to get in. I ran into the following issues:
* test_ShowWindow behaves very strangely on Windows. It seems this isn't typical behavior, and is caused by an interaction with test_SetFocus, but I'm not sure exactly what it does to the thread state that causes this.
* Many of the SetWindowPos flag combinations tested don't actually show the window on Windows, therefore they don't send EVENT_SYSTEM_FOREGROUND. I was able to reproduce this with a stand-alone test, so it seems to be normal behavior.
* Windows can show a window without activating it, and Wine on X11 can't do that reliably for managed windows.
* There are a couple of cases where Windows sends an event and Wine doesn't. I figure it's OK to not cover every case, but I can go back and investigate those if needed.
This interacts with https://gitlab.winehq.org/wine/wine/-/merge_requests/2314, in that the tests don't really test much without it. I applied that MR for my own testing.
--
v3: win32u: Implement EVENT_SYSTEM_FOREGROUND.
user32: Run tests that notice focus changes early.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2853