This MR adds clipboard support to the winewayland driver.
Under Wayland only applications that have the keyboard focus can interact with the clipboard (a.k.a. `wl_data_device`). Such constraints are not a natural fit for Wine's current clipboard infrastructure, which uses a separate thread and window in the desktop process to act as the win32-side clipboard proxy for all native windows.
This MR tries to work within the current Wine clipboard Wine by forwarding relevant clipboard messages to the foreground window which is likely to have the keyboard focus and that can actually handle them. This works well in practice (although there are some edge cases this fails), but I am open to different ideas about implementing the clipboard integration.
Some notes about the MR:
1. Some formats that require special treatment (e.g., CF_HTML, CF_HDROP) are not implemented in this MR to keep the size reasonable (and also to not distract from the goal of this MR which is to propose/discuss the basic design of clipboard integration).
2. Dynamic registration of newly-seen/unknown formats is not supported at the moment. It's not clear to what degree that's useful, since many (most?) Windows clipboard format strings are free-form and don't use the MIME type standard. But perhaps enough Windows apps know about MIME types nowadays to make this addition worth it?
3. Since access to the Wayland clipboard data is performed from the focused window threads (rather than the dedicated clipboard thread), any blocking while waiting for data to be sent/received has more potential to affect the applications. I have implemented reasonable timeouts which are hopefully enough to make this a non-issue. A (more complex) alternative would be a different design that attempts to offload any potentially blocking work to the dedicated clipboard thread (or is there some kind of async read/write mechanism we can use?). I am not convinced the extra complexity is worth it, though.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7236
This fixes https://bugs.winehq.org/show_bug.cgi?id=52094.
--
v8: ntdll: Properly track refcount with forwarded exports.
ntdll: Don't re-add a module dependency if it already exists.
ntdll: Remove some unnecessary NULL checks for current_importer.
ntdll: Set export forwarder DLL as the dynamic importer in LdrGetProcedureAddress().
ntdll: Wrap current_modref variable in a new structure.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7
posix_fallocate() looks like a better fit when increasing allocation size but you'd need to check the file size first, which introduces a race condition. posix_fallocate() will also increase the file size if the file is truncated by another thread.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7115#note_93690
--
v2: wined3d: Remove FOGVERTEXMODE handling from find_ps_compile_args().
wined3d: Remove the redundant per_vertex_point_size from vs_compile_args.
wined3d: Do not toggle point sprite.
wined3d: Do not disable point sprite in wined3d_context_gl_apply_blit_state().
https://gitlab.winehq.org/wine/wine/-/merge_requests/7260
This PR updates the behaviour of `NtQueryDirectoryFile`, bringing it in line with current Windows behaviour. The need for this update was discovered when attempting to build the Unreal Engine with MSVC under Wine. In certain cases conditional include statements do not behave as expected, due to MSVC depending on undocumented behaviour of `NtQueryDirectoryFile`.
We ran tests on multiple versions of Windows, and discovered that the behaviour has changed since the original Wine implementation, but the documentation has not. The source code for our test tool, and a set of results can be found [here](https://github.com/TensorWorks/NtQueryDirectoryFile-Test). As of Windows 8, calling `NtQueryDirectoryFile` with a re-used handle, a new mask, and setting the `RestartScan` flag to True, causes the cached results to be erased and a new scan to be performed with the updated mask. Currently, Wine performs as did earlier versions of Windows, where the changed mask is ignored, and the cache is reused. This can cause `NtQueryDirectoryFile` under Wine to falsely report that files exist, when they do not.
This PR corrects this behaviour, invalidating the cache when required. Implementing this exposed further undocumented behaviour of `NtQueryDirectoryFile`, where a search for a non-existent file will return either `STATUS_NO_MORE_FILES` or `STATUS_NO_SUCH_FILE`, depending on whether or not the handle had been previously used regardless of the value of `RestartScan`. This was reflected in a `winetest` which allowed for the response to be either `STATUS_SUCCESS` or `STATUS_NO_MORE_FILES`.
This patch also adds unit tests for the new behaviour of `NtQueryDirectoryFile`. These tests pass when running `winetest` under Windows, and under Wine with these changes in place, but they will fail under older versions of Wine. If run under older versions of Windows the test suite will detect that this functionality is not supported, and will not run the updated tests.
--
v11: ntdll.dll: Update NtQueryDirectoryFile to align with current Windows behaviour
https://gitlab.winehq.org/wine/wine/-/merge_requests/6904