This is to prevent NULL pointers when creating a TextService with no rows in it.
This NULL pointers doesn't happen when creating a richedit windows, because
it sets an empty text when the richedit window procedure handles the WM_CREATE event.
--
v7: riched20: Call ME_UpdateRepaint instead of editor_ensure_visible in set_selection.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2941
First we set the EOS state, so the wait_parser_stream_buffer function doesn't
call pthread_cond_wait again. Then we must call pthread_cond_signal to make sure
that no one is waiting for it, if we don't do that, there is the possibility of
hanging wg_parser_disconnect at the free_stream call, because pthread_cond_destroy
will hang when the cond object is being waited by other threads.
Specifically this helps to fix a hang in some applications, specially Unreal Engine
games when changing sources too fast in a MediaPlayer.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2887
This is to prevent NULL pointers when creating a TextService with no rows in it.
This NULL pointers doesn't happen when creating a richedit windows, because
it sets an empty text when the richedit window procedure handles the WM_CREATE event.
--
v6: riched20: Call ME_UpdateRepaint instead of editor_ensure_visible in set_selection.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2941
--
v7: vkd3d-shader/hlsl: Handle 'texkill' jump type.
vkd3d-shader/hlsl: Parse clip() function.
tests: Add some tests for clip().
vkd3d-shader: Make some helpers available from hlsl.c.
vkd3d-shader/hlsl: Add a parameter for jump nodes and use it for 'discard'.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/211
On Thu Jun 8 10:13:38 2023 +0000, Huw Davies wrote:
> Yes. See the existing tests in `dlls/riched20/tests/txtsrv.c`. We
> don't currently do much testing on which `ITextHost` members get called,
> but at least there's already an implementation there to get you started.
From what I see when reading the trace calls with `WINETEST_DEBUG` set, windows calls two times TxViewChange, I suppose the first time it's called by the SetText call, and then the second one is called by EM_SETSEL, in wine we don't call it. There are also other functions from the TextHost that get called and we don't do it in wine, so I'm going to write tests for it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2941#note_35179
Currently only used to keep rawinput devices updated without iterating the entire list on every change.
This thread will then let us solve several problems:
* Solve issues with input not being polled if/when applications aren't checking their messages. This removes the need for polling messages in DInput, which is known to confuse and break DOSBOX.
* Solve some issues with ll-hook deadlocks between hooking threads and the thread that is currently polling for inputs.
* Useful to process internal messages and implement some user driver mechanisms. It can for instance already process WM_WINE_CLIPCURSOR messages, instead of relying on the foreground thread.
* Similarly, for cursor icon changes, wineserver can notify it on cursor window changes and request the cursor icon to be updated from the user driver, instead of having to check the window the cursor is located in to change its icon on every mouse move.
* Ultimately make it possible to drop the __wine_send_input PE export, the thread can read HID reports from devices that a process has registered for, and send WM_INPUT messages accordingly. This has some drawbacks though, as reading NT devices currently involves much more wineserver roundtrips than `__wine_send_input`.
There's evidence that Windows uses a similar thread to process hardware events (as described in https://devblogs.microsoft.com/oldnewthing/20140213-00/?p=1773), although it's probably a system-wide kernel thread. I considered reading X11 input from a per-prefix dedicated thread (for instance in explorer.exe) or dedicated process, but having one thread per-process has several advantages.
The rawinput device registration state is done per-process and according to https://gitlab.winehq.org/wine/wine/-/merge_requests/2120 it also needs to post notifications that are process specific.
It also keeps the guarantee that each process will read the inputs from the window it has created, and not from some other windows, although the message dispatch may decide to send the message to another process later, it avoids having to listen to input on other processes windows.
It can then be seen as an intermediate step towards having a per-prefix thread, if that's something we end up needing. Moving from a per-process thread to a per-prefix thread should be easier.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3024
If read_identity returns FALSE, it has already called clear_identity.
This is the same problem as in merge request !2970. Unfortunately I did not notice at first that the problem was present in two places.
--
v2: wusa: Fix double free on error path in read_components (scan-build).
https://gitlab.winehq.org/wine/wine/-/merge_requests/3013