May 2023 - Wine-GitLab - list.winehq.org

[PATCH v2 0/5] MR2944: winewayland.drv: First window contents on screen
by Alexandros Frantzis (＠afrantzis) June 2, 2023

June 2, 2023

The goal of this MR is to set up the minimum necessary infrastructure to display the contents of some simple, software rendered windows. This involves two major steps: 1. Associate a window with a Wayland surface and give it the `xdg_toplevel` role, so that the compositor can display it. We also have to implement the required initial `xdg_surface` configuration sequence to be able to safely (i.e., without the compositor disconnecting us with an error) attach buffers to the surface in step (2). 2. Implement the `window_surface` interface for the Wayland driver. For now we provide a simple (and suboptimal) `window_surface_flush` implementation: for each flush we create a new `wl_shm` buffer, copy the whole window contents (ignoring damaged bounds for now) into it and attach it to the target Wayland surface. In the next MR I will optimize this implementation in multiple ways: a. implement a buffer queue to avoid constantly allocating new buffers b. respect the damaged bounds of the `window_surface` to minimize copying of data from the `window_surface` to the SHM buffer (and also for correctness) c. communicate damaged surface regions to the compositor to (potentially) allow more efficient texture uploads. With this MR many (software-rendered) applications can now display dynamic content on screen. We can't interact with the apps yet, but we do get to enjoy `notepad` in all its blinking-cursor glory. Thanks! -- v2: winewayland.drv: Implement a simple window_surface flush. https://gitlab.winehq.org/wine/wine/-/merge_requests/2944

3 20

[PATCH 0/7] MR2942: jscript: Misc fixes and improvements.
by Gabriel Ivăncescu June 2, 2023

June 2, 2023

Some of these fixes are subtle (like the first patch) and very annoying to debug. Although the first patch looks like a hack, surprisingly, it's how the spec itself says it is! It's not even an IE quirk, but a special case in the spec. For example, the variable name (which holds the builtin eval func) **does** matter: if it's called something other than 'eval', it gets treated differently (as if indirect), and this is verified by the tests + the spec's wording (so Microsoft's implementation follows it). Most of the patches other than the first 2 are pretty small so they're in same MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2942

2 15

[PATCH v3 0/2] MR2866: server: Update parent window region when exposing previously invisible window. (#54949)
by Jinoh Kang (＠iamahuman) June 2, 2023

June 2, 2023

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54949 -- v3: server: Update parent window region when exposing previously invisible window. https://gitlab.winehq.org/wine/wine/-/merge_requests/2866

4 5

[PATCH 0/9] MR2934: sapi: Partially implement SpMMAudioOut.
by Shaun Ren (＠shaunren) June 2, 2023

June 2, 2023

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/2934

4 12

[PATCH v4 0/3] MR2905: sapi: implement more token functionality.
by Shaun Ren (＠shaunren) June 2, 2023

June 2, 2023

-- v4: sapi: Implement token filtering and sorting in ISpObjectTokenEnumBuilder. sapi: Partially reimplement ISpObjectTokenEnumBuilder storing a token array. https://gitlab.winehq.org/wine/wine/-/merge_requests/2905

3 5

[PATCH v3 0/3] MR2274: ntdll: Add source file and line to debug traces.
by Rémi Bernon June 2, 2023

June 2, 2023

-- v3: ntdll: Add return address information in __wine_debug_context. ntdll: Add file and line information in __wine_debug_context. ntdll: Introduce struct __wine_debug_context for extensible debug info. https://gitlab.winehq.org/wine/wine/-/merge_requests/2274

2 6

[PATCH v2 0/4] MR2830: Reimplement dbghelp.EnumerateLoadedModules.
by eric pouech (＠epo) June 2, 2023

June 2, 2023

The aim of this serie is to (re)implement dbghelp.EnumerateLoadedModules in order to return correct 32bit & 64bit modules information for a 32bit debuggee from a 64bit debugger. - In this case, Wine ntdll (incorrectly) stores the paths in LdrData (for system modules) within the syswow64 directory while native stores them within the system32 directory (except for 32bit ntdll which Wine correctly stores within system32). - So now dbghelp implements the system32 => syswow64 path rewrite (for the relevant cases), which is currently used only for ntdll. - This allows: - to be transparent in dbghelp if ntdll is fixed to store the same path as native - the paths returned by dbghelp are consistent with native (in the 64bit debugger / 32bit debuggee case mentionned above) It must be noted that the remaining todo:s in tests are only for the case of a 32bit debugger / 32bit debuggee in (old|new) wow setup, where the returned paths are the (untouched from ntdll) paths, hence in syswow64 when native reports them from system32. - this patch doesn't modify the returned path, and we haven't noticed any issue so far - with redirection in place, access to the image files should be tranparent - so we can keep it as is (not fixing ntdll). -- v2: dbghelp: Reimplement EnumerateLoadedModules(). dbghelp/tests: Add more test wrt. modules's imagename handling. dbghelp/test: Review old-wow64 expected values. dbghelp/tests: Fix process kind detection on old Windows machines. https://gitlab.winehq.org/wine/wine/-/merge_requests/2830

2 6

[PATCH v11 0/6] MR2786: Add support for AF_UNIX sockets
by Ally Sommers (＠dropbear) June 1, 2023

June 1, 2023

Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver. Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options: * Pass the Windows path to wineserver and do the conversion there. * This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons. * Obtain the current working directory of the requesting process and temporarily change directories to there. * This only handles relative paths and fails for absolute paths, UNC paths, etc. * Conditionally change directories based on whether the path is relative or not. * This is error-prone and wineserver does not have the requisite functions to do this cleanly. I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded. Abstract sockets are supported by this patch. -- v11: ws2_32/tests: Add test for AF_UNIX sockets. https://gitlab.winehq.org/wine/wine/-/merge_requests/2786

4 10

[PATCH v2 0/4] MR2919: winsock: Make more waits alertable.
by Paul Gofman (＠gofman) June 1, 2023

June 1, 2023

-- v2: ws2_32: Test wait alertability in WSAGetOverlappedResult(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2919

3 5

[PATCH v2 0/1] MR2941: riched20: Set empty text by default in CreateTextServices.
by Santino Mazza (＠tati1454) June 1, 2023

June 1, 2023

This is to prevent NULL pointers when creating a standalone text service that doesn't have any text set and then using functions like EM_SETSEL. 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. -- v2: riched20: Set empty text by default in CreateTextServices. https://gitlab.winehq.org/wine/wine/-/merge_requests/2941

3 4