- wine-gitlab - winehq.org

Re: [PATCH v2 0/2] MR2114: kernelbase: Fix performance of beatmap search in osu! Stable.
by Torge Matthies (＠tmatthies) 08 Feb '23

08 Feb '23

I can remove the second commit if desired, the first commit is enough to make performance acceptable again. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2114#note_23389

1 0

[PATCH v2 0/4] MR2127: ntdll: Load known dlls from system directory
by Paul Gofman (＠gofman) 07 Feb '23

07 Feb '23

The practical issue I am trying to solve is the following scenario (encountered with a game using some Uplay plugin) which has regressed with apisets implementation in Wine. The game imports ucrtbase.dll. Then, a plugin calls GetModuleHandle("api-ms-win-crt-runtime-l1-1-0.dll") and expects GetProcAddress("\_crt_atexit") to succeed on the returned handle. The problem is that the game has ucrtbase.dll in its .exe directory. That one currently gets loaded. Then, find_dll_file() resolves api-ms-win-crt-runtime-l1-1-0.dll to the ucrtbase with a full path in system32 and tries to find that one (this part matches Windows behaviour as far as tests show). Since we have ucrtbase loaded with another path this results in NULL module handle. Windows maintains the list of "Known DLLs" (probably aimed for speeding up processes startup by using pre-mapped dll images for commonly used system dlls). On Windows, known dlls have specifics in load path resolution when dll name doesn't contain path (relative or full): - they are loaded from system directory even if there is another dll with the same name in priority search path; - they are found even if library search paths do not contain system directory; Those "Known DLLs" are basically listed in HKLM\\System\\CurrentControlSet\\Control\\Session Manager\KnownDLLs registry key. But the actual list of "known dlls" is bigger (probably includes all dependencies of those listed under registry key). The full actual list of "known dlls" is in '\\KnownDlls\' directory object which contains image sections under dll names. Most notably, ucrtbase.dll (which is of the concern in the regression) is not listed in registry but is present in \\KnownDlls. Technically nothing prevents us from implementing these mechanics and creating directory object with mapped load dlls, also resolving the explicitly listed dlls' dependencies. But it is not apparent to me if that is going to improve load times noticably in Wine, and also that is worth the inherent complications until anything actually depends on that \\KnownDlls sections. So instead of implementing all of that throughout the loader I added a few missing dlls to registry. The current list in this pat chset corresponds to the contents of \\KnownDlls directory on an up to date Windows 10. -- v2: ntdll: Load known dlls from system directory. https://gitlab.winehq.org/wine/wine/-/merge_requests/2127

3 6

[PATCH v3 0/4] MR2127: ntdll: Load known dlls from system directory
by Paul Gofman (＠gofman) 07 Feb '23

07 Feb '23

The practical issue I am trying to solve is the following scenario (encountered with a game using some Uplay plugin) which has regressed with apisets implementation in Wine. The game imports ucrtbase.dll. Then, a plugin calls GetModuleHandle("api-ms-win-crt-runtime-l1-1-0.dll") and expects GetProcAddress("\_crt_atexit") to succeed on the returned handle. The problem is that the game has ucrtbase.dll in its .exe directory. That one currently gets loaded. Then, find_dll_file() resolves api-ms-win-crt-runtime-l1-1-0.dll to the ucrtbase with a full path in system32 and tries to find that one (this part matches Windows behaviour as far as tests show). Since we have ucrtbase loaded with another path this results in NULL module handle. Windows maintains the list of "Known DLLs" (probably aimed for speeding up processes startup by using pre-mapped dll images for commonly used system dlls). On Windows, known dlls have specifics in load path resolution when dll name doesn't contain path (relative or full): - they are loaded from system directory even if there is another dll with the same name in priority search path; - they are found even if library search paths do not contain system directory; Those "Known DLLs" are basically listed in HKLM\\System\\CurrentControlSet\\Control\\Session Manager\KnownDLLs registry key. But the actual list of "known dlls" is bigger (probably includes all dependencies of those listed under registry key). The full actual list of "known dlls" is in '\\KnownDlls\' directory object which contains image sections under dll names. Most notably, ucrtbase.dll (which is of the concern in the regression) is not listed in registry but is present in \\KnownDlls. Technically nothing prevents us from implementing these mechanics and creating directory object with mapped load dlls, also resolving the explicitly listed dlls' dependencies. But it is not apparent to me if that is going to improve load times noticably in Wine, and also that is worth the inherent complications until anything actually depends on that \\KnownDlls sections. So instead of implementing all of that throughout the loader I added a few missing dlls to registry. The current list in this pat chset corresponds to the contents of \\KnownDlls directory on an up to date Windows 10. -- v3: ntdll: Load known dlls from system directory. https://gitlab.winehq.org/wine/wine/-/merge_requests/2127

2 5

[PATCH 0/1] MR2129: loader: In macOS preloader, fix an environment variable sometimes being lost.
by Brendan Shanks (＠bshanks) 07 Feb '23

07 Feb '23

On Ventura (and likely also on Monterey), `dyld`/`libc` seems to store the `environ` pointer from when the preloader launches, ignores any change to `environ` done in the preloader, and then uses that original `environ` in the launched wine process. The preloader has to move the start of the environment down by one, and this was causing the first variable to be lost on Monterey/Ventura. Instead of moving the entire environment, add a dummy variable at the beginning so nothing important is lost. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2129

2 1

[PATCH v4 0/12] MR2123: Wow64 support for wpcap.
by Hans Leidekker (＠hans) 07 Feb '23

07 Feb '23

-- v4: wpcap/tests: Initial tests. wpcap: Try to enable 32-bit mmap() support in libpcap. wpcap: Add wow64 thunks. wpcap: Enable UTF-8 encoding in libpcap. wpcap: Reimplement pcap_loop() on top of pcap_next_ex(). wpcap: Implement pcap_init(). wpcap: Implement pcap_dump_close(). wpcap: Implement pcap_bufsize(). wpcap: Fix an off-by-one error in convert_length_to_ipv6_mask(). wpcap: Make Unix call parameters wow64 compatible. wpcap: Sync spec file with latest version of libpcap. configure: Check for pcap_init() instead of pcap_create(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2123

3 13

[PATCH v8 0/2] MR2100: ntdll: Do not send data to port 0.
by Jason Beetham (＠beef331) 07 Feb '23

07 Feb '23

On Windows it seems sending to port 0 does nothing and does not error. Presently sendmsg errors with EINVAL. This works around it, by checking if it's port 0 then skipping the data. -- v8: ntdll: Do not send data to port 0. https://gitlab.winehq.org/wine/wine/-/merge_requests/2100

2 2

[PATCH 0/4] MR2127: ntdll: Load known dlls from system directory
by Paul Gofman (＠gofman) 07 Feb '23

07 Feb '23

The practical issue I am trying to solve is the following scenario (encountered with a game using some Uplay plugin) which has regressed with apisets implementation in Wine. The game imports ucrtbase.dll. Then, a plugin calls GetModuleHandle("api-ms-win-crt-runtime-l1-1-0.dll") and expects GetProcAddress("\_crt_atexit") to succeed on the returned handle. The problem is that the game has ucrtbase.dll in its .exe directory. That one currently gets loaded. Then, find_dll_file() resolves api-ms-win-crt-runtime-l1-1-0.dll to the ucrtbase with a full path in system32 and tries to find that one (this part matches Windows behaviour as far as tests show). Since we have ucrtbase loaded with another path this results in NULL module handle. Windows maintains the list of "Known DLLs" (probably aimed for speeding up processes startup by using pre-mapped dll images for commonly used system dlls). On Windows, known dlls have specifics in load path resolution when dll name doesn't contain path (relative or full): - they are loaded from system directory even if there is another dll with the same name in priority search path; - they are found even if library search paths do not contain system directory; Those "Known DLLs" are basically listed in HKLM\\System\\CurrentControlSet\\Control\\Session Manager\KnownDLLs registry key. But the actual list of "known dlls" is bigger (probably includes all dependencies of those listed under registry key). The full actual list of "known dlls" is in '\\KnownDlls\' directory object which contains image sections under dll names. Most notably, ucrtbase.dll (which is of the concern in the regression) is not listed in registry but is present in \\KnownDlls. Technically nothing prevents us from implementing these mechanics and creating directory object with mapped load dlls, also resolving the explicitly listed dlls' dependencies. But it is not apparent to me if that is going to improve load times noticably in Wine, and also that is worth the inherent complications until anything actually depends on that \\KnownDlls sections. So instead of implementing all of that throughout the loader I added a few missing dlls to registry. The current list in this pat chset corresponds to the contents of \\KnownDlls directory on an up to date Windows 10. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2127

3 5

Re: [PATCH v2 0/1] MR2113: odbccp32: Append DLL path when loading driver. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2113

1 0

[PATCH v3 0/11] MR2123: Wow64 support for wpcap.
by Hans Leidekker (＠hans) 07 Feb '23

07 Feb '23

-- v3: wpcap/tests: Initial tests. wpcap: Try to enable 32-bit mmap() support in libpcap. wpcap: Add wow64 thunks. wpcap: Enable UTF-8 encoding in libpcap. wpcap: Reimplement pcap_loop() on top of pcap_next_ex(). wpcap: Implement pcap_init(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2123

3 12

Re: [PATCH v2 0/7] MR2117: More improvements in PDB dumping. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2117

1 0

Re: [PATCH v7 0/1] MR1937: kernelbase: Fix grouping repeat for number formatting. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1937

1 0

Re: [PATCH v2 0/8] MR2076: win32u: Introduce and use KBDTABLES structure for nulldrv keyboard layout. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2076

1 0

Re: [PATCH v2 0/1] MR2121: winhlp32: Fix memory leak on realloc failure in HLPFILE_RtfAddBitmap (cppcheck). - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2121

1 0

Re: [PATCH v3 0/4] MR2119: kernelbase: Add QueryInterruptTime and QueryInterruptTimePrecise/QueryUnbiasedInterruptTimePrecise semi-stubs. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2119

1 0

Re: [PATCH v2 0/1] MR2111: nsiproxy: Avoid calling RtlInitUnicodeString on a static constant. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2111

1 0

Re: [PATCH v3 0/1] MR2112: combase: Avoid calling RtlInitUnicodeString on a static constant. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2112

1 0

Re: [PATCH v5 0/3] MR2080: winegstreamer: GetInputStatus for h264, aac and MF_SA_D3D11_AWARE for h264. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2080

1 0

Re: [PATCH v4 0/6] MR1925: WMV decoder DMO support. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1925

1 0

Re: [PATCH v4 0/6] MR2102: Add a partially implemented ir50_32 winmm video decoder, and a stub generic video decoder in winegstreamer. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2102

1 0

Re: [PATCH v3 0/1] MR83: vkd3d-shader: Initialize the parameter allocator head. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/83

1 0

Re: [PATCH v2 0/1] MR79: vkd3d-shader/hlsl: Handle saturate() for SM1. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/79

1 0

Re: [PATCH v4 0/6] MR77: hlsl: Fixes for function definition vs declaration. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/77

1 0

Re: [PATCH v2 0/1] MR82: vkd3d: Fix checking for failure from SleepConditionVariableCS(). - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/82

1 0

Re: [PATCH v2 0/1] MR78: vkd3d: Initialize image aspect for NULL SRVs. - approved
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/78

1 0

[PATCH v2 0/1] MR2125: ntdll/tests: Fix broken broken(<constant>) calls.
by Michael Stefaniuc (＠mstefani) 07 Feb '23

07 Feb '23

-- v2: ntdll/tests: Fix broken broken(<constant>) calls. https://gitlab.winehq.org/wine/wine/-/merge_requests/2125

2 4

[PATCH 0/1] MR2053: wmc: Include config.h from lang.c
by Gerald Pfeifer (＠gerald) 07 Feb '23

07 Feb '23

tools.h uses HAVE_SYS_SYSCTL_H as an include guard which, like others set by configure, is defined in config.h. Make sure we pull that in or we never get to include sys/sysctl.h. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2053

3 3

Re: [PATCH v2 0/1] MR2124: dlls: fix whitespaces in WINE_*_DEBUG_CHANNEL declarations - closed
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

This merge request was closed by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2124

1 0

Re: [PATCH v2 0/1] MR2124: dlls: fix whitespaces in WINE_*_DEBUG_CHANNEL declarations
by Alexandre Julliard (＠julliard) 07 Feb '23

07 Feb '23

Please don't do that sort of thing. Whitespace-only changes should be avoided. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2124#note_23323

1 0

[PATCH 0/1] MR2125: ntdll/tests: Fix broken broken(<constant>) calls.
by Michael Stefaniuc (＠mstefani) 07 Feb '23

07 Feb '23

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

3 2

[PATCH v2 0/11] MR2123: Wow64 support for wpcap.
by Hans Leidekker (＠hans) 07 Feb '23

07 Feb '23

-- v2: wpcap/tests: Initial tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/2123

2 11

[PATCH 0/1] MR79: vkd3d-shader/hlsl: Handle saturate() for SM1.
by Nikolay Sivov (＠nsivov) 07 Feb '23

07 Feb '23

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/79

6 9

[PATCH v6 0/8] MR66: vkd3d-shader/hlsl: Broaden resources support v2 (PART 1).
by Francisco Casas (＠fcasas) 07 Feb '23

07 Feb '23

First part of v2 of !27, which aims to: * Allow allocation of variables of complex types that contain both numerics and objects across multiple register sets (regsets). * Support the tex2D and tex3D intrinsics, inferring generic samplers dimension from usage, writing sampler declarations, and writing sample instructions. * Support for arrays of resources for both SM1 and SM4 (not to be confused with the resource-arrays of SM 5.1, which can have non-constant indexes). * Support for resources declared within structs. * Support for synthetic combined samplers for SM1 and synthetic separated samplers for SM4, considering that they can be arrays or members of structs. * Imitate the way the native compiler assigns the register indexes of the resources on allocation, which proved to be the most difficult thing. * Support for object components within complex input parameters. * Small fixes to corner cases. This part consists on parsing the `tex2D()` and `tex3D()` intrinsics and beginning to support the allocation of variables across multiple regsets. The whole series, is on my [master6](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/master6) branch. -- v6: vkd3d-shader/hlsl: Allocate register reservations in a separate pass. vkd3d-shader/hlsl: Respect object reservations even if the object is unused. vkd3d-shader/hlsl: Allocate objects according to register set. vkd3d-shader/hlsl: Keep an hlsl_reg for each register set in hlsl_ir_var. vkd3d-shader/hlsl: Store the type's register size for each register set. vkd3d-shader/hlsl: Parse the tex3D() intrinsic. vkd3d-shader/hlsl: Parse the tex2D() intrinsic. vkd3d-shader/hlsl: Avoid segfault on missing sampler. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/66

4 15

[PATCH v3 0/2] MR2120: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications
by Evan Tang (＠etang-cw) 07 Feb '23

07 Feb '23

This seems to be relied on by some versions of [this Unreal Engine input plugin](https://www.unrealengine.com/marketplace/en-US/product/wm-input-man… Note: I'm not sure how to deal with `HID_USAGE_GENERIC_KEYPAD`, which (I think) would fall under `RIM_TYPEKEYBOARD`. Do we need to store extra info to differentiate these from `HID_USAGE_GENERIC_KEYBOARD` or is there something in the device info struct that can differentiate them? -- v3: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications https://gitlab.winehq.org/wine/wine/-/merge_requests/2120

4 5

[PATCH 0/1] MR1963: d3dcompiler_43/tests: Allow more imprecision in test_trig() for NVIDIA.
by Francois Gouget (＠fgouget) 07 Feb '23

07 Feb '23

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

3 2

[PATCH 0/9] MR2122: Draft: winex11: Support fixed X11 keycode to scancode conversion.
by Rémi Bernon (＠rbernon) 07 Feb '23

07 Feb '23

X11 keycodes are just Linux keycodes + 8 nowadays according to evdev or libinput drivers, and we can avoid innacurate reconstruction in the most common case. Opening this as a draft for now, to show where I'd like to go with https://gitlab.winehq.org/wine/wine/-/merge_requests/2062. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2122

3 10

[PATCH v8 0/4] MR1088: ntdll: Avoid calling pthread_exit on thread exit.
by Rémi Bernon (＠rbernon) 07 Feb '23

07 Feb '23

Using a dedicated exit jmpbuf and removing the need for assembly routines. When Wine handles an exception in unix code, we return to user mode by jumping to the last syscall frame. This can leave some pthread cancel cleanups registered, in the pthread internal linked list, and at the same time later overwrite the stack frame they were registered for. In the same way, jumping to the exit frame on thread exit or abort, can also leave some cleanup handlers registered for invalid stack frames. Depending on the implementation, calling pthread_exit will cause all the registered pthread cleanup handlers to be called, possibly jumping back to now overwritten stack frames and causing segmentation faults. Exiting a pthread normally, by returning from its procedure, or calling exit(0) for the main thread doesn't run pthread_exit and doesn't call cleanup handlers, avoiding that situation. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213 ### Additional note: For robustness, we should probably try to execute these cleanup handlers when unwinding the stack frames, as we would otherwise leave pthread objects in a potential problematic state (like a mutex locked, etc). It is however hard to do so when the handlers are registered from some C code: pthread C implementation is done by calling some internal pthread functions to register the handlers, and they aren't registered as standard unwind handlers. Only pthread_cancel and pthread_exit can unwind and call / unregister the C handlers, but interrupting that procedure, for instance calling setjmp / longjmp from withing our own handler isn't supported. From C++ code, pthread cleanup handlers are registered through C++ class constructors / destructors, and it would then be possible to partially unwind and call them at the same time. -- v8: ntdll: Remove now unnecessary arch-specific exit frame. ntdll: Avoid calling pthread_exit on thread exit. ntdll: Return entry and suspend from server_init_process_done. ntdll: Create a pthread for the main thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/1088

3 7

[PATCH v7 0/4] MR1088: ntdll: Avoid calling pthread_exit on thread exit.
by Rémi Bernon (＠rbernon) 07 Feb '23

07 Feb '23

Using a dedicated exit jmpbuf and removing the need for assembly routines. When Wine handles an exception in unix code, we return to user mode by jumping to the last syscall frame. This can leave some pthread cancel cleanups registered, in the pthread internal linked list, and at the same time later overwrite the stack frame they were registered for. In the same way, jumping to the exit frame on thread exit or abort, can also leave some cleanup handlers registered for invalid stack frames. Depending on the implementation, calling pthread_exit will cause all the registered pthread cleanup handlers to be called, possibly jumping back to now overwritten stack frames and causing segmentation faults. Exiting a pthread normally, by returning from its procedure, or calling exit(0) for the main thread doesn't run pthread_exit and doesn't call cleanup handlers, avoiding that situation. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213 ### Additional note: For robustness, we should probably try to execute these cleanup handlers when unwinding the stack frames, as we would otherwise leave pthread objects in a potential problematic state (like a mutex locked, etc). It is however hard to do so when the handlers are registered from some C code: pthread C implementation is done by calling some internal pthread functions to register the handlers, and they aren't registered as standard unwind handlers. Only pthread_cancel and pthread_exit can unwind and call / unregister the C handlers, but interrupting that procedure, for instance calling setjmp / longjmp from withing our own handler isn't supported. From C++ code, pthread cleanup handlers are registered through C++ class constructors / destructors, and it would then be possible to partially unwind and call them at the same time. -- v7: ntdll: Remove now unnecessary arch-specific exit frame. ntdll: Avoid calling pthread_exit on thread exit. ntdll: Return entry and suspend from server_init_process_done. ntdll: Create a pthread for the main thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/1088

4 9

[PATCH v3 0/6] MR77: hlsl: Fixes for function definition vs declaration.
by Zebediah Figura (＠zfigura) 07 Feb '23

07 Feb '23

-- v3: vkd3d-shader/hlsl: Add functions to the global list inside the func_prototype rule. vkd3d-shader/hlsl: Use the original hlsl_ir_function_decl struct rather than allocating a new one for each definition. vkd3d-shader/hlsl: Put synthetic variables into a dummy scope. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/77

4 10

[PATCH v2 0/5] MR81: vkd3d-shader/hlsl: Fixes for SM1 writemasks and swizzles.
by Francisco Casas (＠fcasas) 07 Feb '23

07 Feb '23

Because of the change introduced in f21693b2, SM1 scalars and vectors were not longer getting the correct writemask when they are allocated, so this is fixed. Also, the mapping of sm1 src register swizzles is moved outside `write_sm1_instruction()` since there are some instructions that don't do this, remarkably dp2add. This is fixed. Before the last patch we are writing the operation as: ``` dp2add r0.x, r1.x, r0.x, r2.x ``` and now it is: ``` dp2add r0.x, r1.xyxx, r0.xyxx, r2.x ``` dp2add now has its own function, `write_sm1_dp2add()`, since it seems to be the only instruction with this structure. Ideally we would be using the default swizzles for the first two src arguments: ``` dp2add r0.x, r1, r0, r2.x ``` since, according to native's documentation, these are supported for all sm < 4. But using default swizzles whenever is possible -- along with following the conversion of repeating the last component of the swizzle when fewer than 4 components are to be specified -- has a higher scope. Probably would involve modifying `hlsl_swizzle_from_writemask()` and `hlsl_map_swizzle()`. -- v2: vkd3d-shader/hlsl: Fix SM1 dp2add swizzles. vkd3d-shader/hlsl: Map SM1 src swizzles outside write_sm1_instruction(). vkd3d-shader/hlsl: Set writemasks correctly for SM1 scalar and vector types. vkd3d-shader/hlsl: Expect component count in allocate_register(). vkd3d-shader/hlsl: Rename 'component_count' arguments to 'reg_size'. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/81

5 9

[PATCH 0/11] MR2123: Wow64 support for wpcap.
by Hans Leidekker (＠hans) 07 Feb '23

07 Feb '23

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

3 12

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Rémi Bernon (＠rbernon) 07 Feb '23

07 Feb '23

On Mon Feb 6 15:36:14 2023 +0000, Timo Zuccarello wrote: > Is there anything I can help with? I obviously have a bit of a personal > interest in having this "fixed" finally. Well if you feel like it, you can always have a look at the MR and review the changes. I also opened https://gitlab.winehq.org/wine/wine/-/merge_requests/2122 with the complete changes, if you want to give it a try, and confirm that it does the right thing for you as well. I've done a bit of testing but I don't often use any very fancy keyboard layout either. Then I suspect that what's expected here is actually a bit more wider testing, so probably I should try to get this into Wine Staging or Proton first. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23264

1 0

[PATCH v6 0/7] MR1628: ntdll: Implement Low Fragmentation Heap.
by Rémi Bernon (＠rbernon) 07 Feb '23

07 Feb '23

Not completely sure if it's worth having for 8.0, but opening this to share the target I'm trying to reach. -- v6: ntdll: Add a thread-specific category group cache. ntdll: Use atomics and lock-free list for category groups. ntdll: Implement Low Fragmentation Heap frontend. ntdll: Count allocations and automatically enable LFH. ntdll: Increase heap block tail_size capacity to 16 bits. ntdll: Implement HeapCompatibilityInformation. ntdll: Fix HeapWalk with empty uncommitted consecutive subheaps. https://gitlab.winehq.org/wine/wine/-/merge_requests/1628

4 57

[PATCH 0/1] MR2111: nsiproxy: Avoid calling RtlInitUnicodeString on a static constant.
by Alex Henrie (＠alexhenrie) 07 Feb '23

07 Feb '23

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

3 2

[PATCH v2 0/1] MR2112: combase: Avoid calling RtlInitUnicodeString on a static constant.
by Alex Henrie (＠alexhenrie) 07 Feb '23

07 Feb '23

-- v2: combase: Avoid calling RtlInitUnicodeString on a static constant. https://gitlab.winehq.org/wine/wine/-/merge_requests/2112

3 2

[PATCH v3 0/5] MR2103: Draft: Add support for WinRT app dark mode
by Mohamad Al-Jaf (＠maljaf) 07 Feb '23

07 Feb '23

WinRT apps check if the Windows theme is set to dark mode through IUISettings3::GetColorValue(). An option needs to be added to Winecfg to enable dark mode support, which just sets the registry key AppsUseLightTheme to 0 for dark mode and 1 for light mode. It will have to be in a separate merge request. Also, not sure if a dark mode checkbox should be added or if dark mode should be automatically set based on the loaded theme in Wine. Though, for the latter there needs to be a property that returns the mode of the theme. Name alone might not be sufficient. -- v3: windows.ui/tests: Add IUISettings3::GetColorValue() tests. windows.ui: Implement IUISettings3::GetColorValue(). windows.ui: Add IUISettings3 stub interface. windows.ui: Add stub DLL. https://gitlab.winehq.org/wine/wine/-/merge_requests/2103

3 22

[PATCH v2 0/2] MR2120: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications
by Evan Tang (＠etang-cw) 07 Feb '23

07 Feb '23

This seems to be relied on by some versions of [this Unreal Engine input plugin](https://www.unrealengine.com/marketplace/en-US/product/wm-input-man… Note: I'm not sure how to deal with `HID_USAGE_GENERIC_KEYPAD`, which (I think) would fall under `RIM_TYPEKEYBOARD`. Do we need to store extra info to differentiate these from `HID_USAGE_GENERIC_KEYBOARD` or is there something in the device info struct that can differentiate them? -- v2: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications user32: Add tests for WM_INPUT_DEVICE_CHANGE messages https://gitlab.winehq.org/wine/wine/-/merge_requests/2120

4 7

[PATCH v5 0/6] MR2091: windows.media.speech: Initial Unixlib work.
by Bernhard Kölbl (＠besentv) 07 Feb '23

07 Feb '23

Second commit is to be removed. Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com> -- v5: windows.media.speech: Implement Vosk create and release functions in the unixlib. https://gitlab.winehq.org/wine/wine/-/merge_requests/2091

4 20

[PATCH 0/8] MR2076: win32u: Introduce and use KBDTABLES structure for nulldrv keyboard layout.
by Rémi Bernon (＠rbernon) 07 Feb '23

07 Feb '23

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

2 9

[PATCH 0/1] MR1665: kernelbase: Let GetFileInformationByHandle succeed on unix redirected handle.
by eric pouech (＠epo) 07 Feb '23

07 Feb '23

As these handles to a file don't have an unix-name attached, the FileAllInformation query fails. So only implement GetFileInformationByHandle() on top of queries which don't fail. I tested if the three ntdll calls instead of one did impact performance. On cached handles they don't: a simple x100000 loop even shows a ~10% improvement, likely because we don't grab the filename from wineserver. Note: that NtQueryInformationFile(FileAllInformation) (as other queries returning file's name) will still fail on these unix-redirected handles. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51813 Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1665

7 15

[PATCH v6 0/1] MR2118: ntdll: Explaining with wine requires a 3G/1G split on 32bit
by Steve Schnepp (＠steveschnepp) 07 Feb '23

07 Feb '23

Windows has a 2G/2G split by default, but some addresses are fixed in the win32 API, so we have to ensure that those addresses are still available in the virtual memory space and not taken by Linux. Kudos to stefand for taking the time to explain on IRC. -- v6: ntdll: Explaining why 3G/1G split is needed on 32bit https://gitlab.winehq.org/wine/wine/-/merge_requests/2118

2 1

[PATCH v2 0/4] MR2119: kernelbase: Add QueryInterruptTime and QueryInterruptTimePrecise/QueryUnbiasedInterruptTimePrecise semi-stubs.
by Brendan Shanks (＠bshanks) 07 Feb '23

07 Feb '23

Swift for Windows uses `QueryInterruptTimePrecise` and `QueryUnbiasedInterruptTimePrecise`. These are semi-stubs since (I believe) the "Precise" variants should read the CPU timestamp directly rather than reading from USER_SHARED_DATA. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54338 -- v2: kernelbase: Partially implement QueryUnbiasedInterruptTimePrecise. kernelbase: Partially implement QueryInterruptTimePrecise. kernelbase: Implement QueryInterruptTime. include: Add realtimeapiset.h file. https://gitlab.winehq.org/wine/wine/-/merge_requests/2119

4 7

[PATCH 0/2] MR2017: kernelbase: Partially implement QueryUnbiasedInterruptTimePrecise.
by Mohamad Al-Jaf (＠maljaf) 07 Feb '23

07 Feb '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54338 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2017

3 6

[PATCH 0/4] MR84: vkd3d-shader/spirv: Normalise inputs and outputs to the Shader Model 6 pattern.
by Conor McCarthy (＠cmccarthy) 07 Feb '23

07 Feb '23

Multiple fork and join phases are eliminated. Signature elements are merged where required, and all input/output parameters are rewritten. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/84

2 5

[PATCH 0/1] MR2121: winhlp32: Fix memory leak on realloc failure in HLPFILE_RtfAddBitmap (cppcheck).
by Alex Henrie (＠alexhenrie) 07 Feb '23

07 Feb '23

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

2 1

[PATCH v4 0/3] MR2080: winegstreamer: GetInputStatus for h264, aac and MF_SA_D3D11_AWARE for h264.
by Paul Gofman (＠gofman) 07 Feb '23

07 Feb '23

Needed for Gungrave G.O.R.E. (besides some bits in raw AAC handling). The game is fine with GetInputStatus always returning MFT_INPUT_STATUS_ACCEPT_DATA for both h264 and aac but I think it is better to be correct here. -- v4: winegstreamer: Set MF_SA_D3D11_AWARE attribute for h264 transform. winegstreamer: Implement _GetInputStatus() for aac decoder transform. https://gitlab.winehq.org/wine/wine/-/merge_requests/2080

6 12

[PATCH v3 0/6] MR1925: WMV decoder DMO support.
by Ziqing Hui (＠zhui) 06 Feb '23

06 Feb '23

-- v3: winegstreamer: Implement GetOutputSizeInfo for WMV decoder. mf/tests: Test GetOutputSizeInfo for WMV decoder. winegstreamer: Implement SetOutputType for WMV decoder. winegstreamer: Implement GetOutputType for WMV decoder. mfplat: Support YVYU, NV11, MEDIASUBTYPE_RGB* media types. mfplat: Fix stride calculation for RGB24. https://gitlab.winehq.org/wine/wine/-/merge_requests/1925

4 9

Re: [PATCH v7 0/2] MR2100: ntdll: Do not send data to port 0.
by Jason Beetham (＠beef331) 06 Feb '23

06 Feb '23

On Mon Feb 6 08:42:38 2023 +0000, **** wrote: > Marvin replied on the mailing list: > ``` > Hi, > It looks like your patch introduced the new failures shown below. > Please investigate and fix them before resubmitting your patch. > If they are not new, fixing them anyway would help a lot. Otherwise > please ask for the known failures list to be updated. > The tests also ran into some preexisting test failures. If you know how > to fix them that would be helpful. See the TestBot job for the details: > The full results can be found at: > https://testbot.winehq.org/JobDetails.pl?Key=129123 > Your paranoid android. > === debian11 (32 bit report) === > ws2_32: > sock.c:13681: Test succeeded inside todo block: got error 0 > sock.c:13682: Test succeeded inside todo block: Failed to send full > data(12) only sent(12) > === debian11 (32 bit ar:MA report) === > ws2_32: > sock.c:13681: Test succeeded inside todo block: got error 0 > sock.c:13682: Test succeeded inside todo block: Failed to send full > data(12) only sent(12) > === debian11 (32 bit de report) === > ws2_32: > sock.c:13681: Test succeeded inside todo block: got error 0 > sock.c:13682: Test succeeded inside todo block: Failed to send full > data(12) only sent(12) > === debian11 (32 bit fr report) === > ws2_32: > sock.c:13681: Test succeeded inside todo block: got error 0 > sock.c:13682: Test succeeded inside todo block: Failed to send full > data(12) only sent(12) > === debian11 (32 bit he:IL report) === > ws2_32: > sock.c:13681: Test succeeded inside todo block: got error 0 > sock.c:13682: Test succeeded inside todo block: Failed to send full > data(12) only sent(12) > === debian11 (32 bit hi:IN report) === > ws2_32: > sock.c:13681: Test succeeded inside todo block: got error 0 > sock.c:13682: Test succeeded inside todo block: Failed to send full > data(12) only sent(12) > === debian11 (32 bit ja:JP report) === > ws2_32: > sock.c:13681: Test succeeded inside todo block: got error 0 > sock.c:13682: Test succeeded inside todo block: Failed to send full > data(12) only sent(12) > === debian11 (32 bit zh:CN report) === > ws2_32: > sock.c:13681: Test succeeded inside todo block: got error 0 > sock.c:13682: Test succeeded inside todo block: Failed to send full > data(12) only sent(12) > === debian11b (32 bit WoW report) === > ws2_32: > sock.c:13681: Test succeeded inside todo block: got error 0 > sock.c:13682: Test succeeded inside todo block: Failed to send full > data(12) only sent(12) > === debian11b (64 bit WoW report) === > ws2_32: > sock.c:13681: Test succeeded inside todo block: got error 0 > sock.c:13682: Test succeeded inside todo block: Failed to send full > data(12) only sent(12) > ``` Looking at the diff I think this was ran on a incorrect rebase(Atleast it looks that way). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2100#note_23183

1 0

[PATCH v2 0/1] MR80: vkd3d-shader/hlsl: Support reflect() intrinsic.
by Nikolay Sivov (＠nsivov) 06 Feb '23

06 Feb '23

-- v2: vkd3d-shader/hlsl: Support reflect() intrinsic. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/80

2 1

[PATCH 0/3] MR2119: kernelbase: Add QueryInterruptTime and QueryInterruptTimePrecise/QueryUnbiasedInterruptTimePrecise semi-stubs.
by Brendan Shanks (＠bshanks) 06 Feb '23

06 Feb '23

Swift for Windows uses `QueryInterruptTimePrecise` and `QueryUnbiasedInterruptTimePrecise`. These are semi-stubs since (I believe) the "Precise" variants should read the CPU timestamp directly rather than reading from USER_SHARED_DATA. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54338 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2119

3 4

[PATCH 0/1] MR2120: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications
by Evan Tang (＠etang-cw) 06 Feb '23

06 Feb '23

This seems to be relied on by some versions of [this Unreal Engine input plugin](https://www.unrealengine.com/marketplace/en-US/product/wm-input-man… Note: I'm not sure how to deal with `HID_USAGE_GENERIC_KEYPAD`, which (I think) would fall under `RIM_TYPEKEYBOARD`. Do we need to store extra info to differentiate these from `HID_USAGE_GENERIC_KEYBOARD` or is there something in the device info struct that can differentiate them? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2120

3 2

[PATCH v5 0/1] MR2118: ntdll: Explaining with wine requires a 3G/1G split on 32bit
by Steve Schnepp (＠steveschnepp) 06 Feb '23

06 Feb '23

Windows has a 2G/2G split by default, but some addresses are fixed in the win32 API, so we have to ensure that those addresses are still available in the virtual memory space and not taken by Linux. Kudos to stefand for taking the time to explain on IRC. -- v5: ntdll: Explaining why 3G/1G split is needed on 32bit https://gitlab.winehq.org/wine/wine/-/merge_requests/2118

2 2

Re: [PATCH v3 0/7] MR2078: Fixes for debugging in new wow64 setup. - approved
by Alexandre Julliard (＠julliard) 06 Feb '23

06 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2078

1 0

Re: [PATCH v2 0/1] MR2109: setupapi: Fix memory leak on realloc failure in RetreiveFileSecurity. - approved
by Alexandre Julliard (＠julliard) 06 Feb '23

06 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2109

1 0

Re: [PATCH v2 0/1] MR2115: programs/conhost: only update font when running with a window. - approved
by Alexandre Julliard (＠julliard) 06 Feb '23

06 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2115

1 0

Re: [PATCH v2 0/1] MR2110: msi: Handle memory allocation failure in get_link_file (cppcheck). - approved
by Alexandre Julliard (＠julliard) 06 Feb '23

06 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2110

1 0

Re: [PATCH v2 0/2] MR2099: tests: Actually test the return value of some function calls - approved
by Alexandre Julliard (＠julliard) 06 Feb '23

06 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2099

1 0

Re: [PATCH v16 0/3] MR1268: wininet: Partially implement InternetSetFilePointer - approved
by Alexandre Julliard (＠julliard) 06 Feb '23

06 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1268

1 0

Re: [PATCH v2 0/1] MR2028: wined3d: Make depth bounds test a proper state and handle it in wined3d_device_apply_stateblock(). - approved
by Alexandre Julliard (＠julliard) 06 Feb '23

06 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2028

1 0

Re: [PATCH v2 0/1] MR2104: wbemprox: Do not call Release() inside wbemprox_cf_CreateInstance(). - approved
by Alexandre Julliard (＠julliard) 06 Feb '23

06 Feb '23

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2104

1 0

[PATCH v3 0/6] MR2102: Add a partially implemented ir50_32 winmm video decoder, and a stub generic video decoder in winegstreamer.
by Shaun Ren (＠shaunren) 06 Feb '23

06 Feb '23

-- v3: ir50_32: Implement open and close. winegstreamer: Add video_decoder stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/2102

2 6

[PATCH v4 0/6] MR2091: windows.media.speech: Initial Unixlib work.
by Bernhard Kölbl (＠besentv) 06 Feb '23

06 Feb '23

Second commit is to be removed. Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com> -- v4: windows.media.speech: Implement Vosk create and release functions in the unixlib. windows.media.speech/tests: Allow the SpeechRecognizer creation to fail in Wine. windows.media.speech/tests: Get rid of duplicated hresult. windows.media.speech: Add a unixlib stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/2091

2 6

[PATCH v4 0/1] MR2118: ntdll: Explaining with wine requires a 3G/1G split on 32bit
by Steve Schnepp (＠steveschnepp) 06 Feb '23

06 Feb '23

Windows has a 2G/2G split by default, but some addresses are fixed in the win32 API, so we have to ensure that those addresses are still available in the virtual memory space and not taken by Linux. Kudos to stefand for taking the time to explain on IRC. -- v4: ntdll: Explaining with wine requires a 3G/1G split on 32bit https://gitlab.winehq.org/wine/wine/-/merge_requests/2118

3 7

[PATCH v3 0/4] MR2091: windows.media.speech: Initial Unixlib work.
by Bernhard Kölbl (＠besentv) 06 Feb '23

06 Feb '23

Second commit is to be removed. Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com> -- v3: windows.media.speech: Implement Vosk create and release functions in the unixlib. windows.media.speech: Add a unixlib stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/2091

5 35

[PATCH v5 0/2] MR76: vkd3d-shader/hlsl: Support rsqrt() and distance() intrinsics.
by Nikolay Sivov (＠nsivov) 06 Feb '23

06 Feb '23

-- v5: vkd3d-shader/hlsl: Support distance() intrinsic. vkd3d-shader/hlsl: Support rsqrt() intrinsic. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/76

3 3

[PATCH v3 0/1] MR2118: ntdll: Explaining with wine requires a 3G/1G split on 32bit
by Steve Schnepp (＠steveschnepp) 06 Feb '23

06 Feb '23

Windows has a 2G/2G split by default, but some addresses are fixed in the win32 API, so we have to ensure that those addresses are still available in the virtual memory space and not taken by Linux. Kudos to stefand for taking the time to explain on IRC. -- v3: ntdll: Explaining with wine requires a 3G/1G split on 32bit https://gitlab.winehq.org/wine/wine/-/merge_requests/2118

2 2

[PATCH v2 0/1] MR2118: ntdll: Explaining with wine requires a 3G/1G split on 32bit
by Steve Schnepp (＠steveschnepp) 06 Feb '23

06 Feb '23

Windows has a 2G/2G split by default, but some addresses are fixed in the win32 API, so we have to ensure that those addresses are still available in the virtual memory space and not taken by Linux. Kudos to stefand for taking the time to explain on IRC. -- v2: ntdll: Explaining with wine requires a 3G/1G split on 32bit https://gitlab.winehq.org/wine/wine/-/merge_requests/2118

4 4

[PATCH v6 0/1] MR1937: kernelbase: Fix grouping repeat for number formatting.
by Gabriel Ivăncescu (＠insn) 06 Feb '23

06 Feb '23

LOCALE_SGROUPING's string and the `Grouping` field in NUMBERFMTW are confusingly different. The former, which is what is fixed here, treats a '0' as a repeat of the previous grouping. But a 0 at the end of the `Grouping` field prevents it from repeating (it repeats by default otherwise) so it's the opposite. Note that without a '0' in the LOCALE_SGROUPING string, it shouldn't even repeat in the first place. This fixes the typical "3;0" default grouping, for example. See: https://learn.microsoft.com/en-us/windows/win32/intl/locale-sgrouping -- v6: kernelbase: Fix grouping repeat for number formatting. https://gitlab.winehq.org/wine/wine/-/merge_requests/1937

2 3

[PATCH 0/1] MR2118: ntdll: Explaining with wine requires a 3G/1G split on 32bit
by Steve Schnepp (＠steveschnepp) 06 Feb '23

06 Feb '23

Windows has a 2G/2G split by default, but some addresses are fixed in the win32 API, so we have to ensure that those addresses are still available in the virtual memory space and not taken by Linux. Kudos to stefand for taking the time to explain on IRC. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2118

2 1

[PATCH 0/5] MR2098: mshtml: Implement synchronous XMLHttpRequests.
by Gabriel Ivăncescu (＠insn) 06 Feb '23

06 Feb '23

wine-gecko does actually support synchronous XMLHttpRequests, even if they are deprecated, but unfortunately it is very broken compared to IE or all the other major browsers (more details [here](https://bugzilla.mozilla.org/show_bug.cgi?id=697151)). Thankfully, it still provides us with the event message loop, which is enough to fix it on mshtml side and act like IE. For sync XHRs, send() is supposed to block all script code, except for notifications sent to the sync XHR. This is because when send() blocks, no other piece of code in the script should execute other than the sync XHR handlers. Unfortunately, that's not the case in Gecko's broken implementation, which can execute handlers as if they were APCs while it's "blocked" in send(). Note that it doesn't actually block, though, because we still process the message loop (non-event related tasks such as navigation, paints, and other stuff), and that's normal. Gecko doesn't block everything related to script events, only some things on the document and timers, but that's far from enough and not even enough for our purposes since we use our own timer tasks. And not even message events are blocked, even though we *also* use our own message event dispatchers (but it doesn't block Gecko ones either). So what we have to do is we need to track all the timers and events dispatched that result in script handlers being executed, while "blocking" inside of a sync XHR send(), and queue them up to defer them to be dispatched later, after send() unblocks. But this is easier said that done. There are many corner cases to consider here, for example: * Events dispatched *synchronously* from within a sync XHR handler or other piece of code called from it. * Nested sync XHR send() calls (called during handler of another sync XHR). * Async XHRs having their events dispatched during a blocking sync XHR send() are complicated. `readyStateChange` for example needs to have the async XHR's readyState at the time it was sent, **not** at the time it was actually dispatched, since we're going to delay it and dispatch it later. It's similar with other XHR states, such as responseText (which can be partial). * Aborts of async XHRs during such handlers. These patches hopefully should address all the issues and, on a high level, work like this: * Track the `readyState` and `responseText` length manually, so we can override / force them to specific values. * "Snapshot" the async XHR at the time we encounter an event for it, and queue this event with such information. When later dispatching this event (after being deferred), we temporarily set the state of the async XHR to the snapshot. * To deal with nested event dispatches, keep track of a "dispatch depth" (everytime we dispatch an event we increase the depth, and when it returns we decrease it). * For sync XHRs, we note the depth when send() is called, and defer events at that depth, since they're dispatched during the "blocked" message loop and need to be delayed (except for sync XHR events, which is a special case since it must be dispatched synchronously). When it returns, we restore the previous blocking depth. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2098

3 7

[PATCH 0/7] MR2117: More improvements in PDB dumping.
by eric pouech (＠epo) 06 Feb '23

06 Feb '23

This series: - complements PDB dumping in a few areas (internals of MSF, string tables, public stream) - allow to opt in for only a portion of PDB file -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2117

2 7

[PATCH 0/1] MR2106: ntdll: Fix path to ntdll for "old" wow64 configuration.
by eric pouech (＠epo) 06 Feb '23

06 Feb '23

For a 32bit process, running in the "old" wow64 configuration, the filename of loaded (32 bit) ntdll.dll is reported as ..\system32\ntdll.dll instead of being in the wow64 directory. This affects: - filename used for image mapping - filename entry in LdrData (Note all the others DLLs in this configuration are correctly exposed in wow64 directory). Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2106

3 4

[PATCH 0/1] MR1764: inetmib1: Get rid of GCC12 warning.
by eric pouech (＠epo) 06 Feb '23

06 Feb '23

Code assumes that tableIndex is never 0, while GCC cannot infer it. So include tableIndex=0 case into already handled error cases. GCC/Mingw complains with: /home/eric/work/wine/dlls/inetmib1/main.c: In function 'mib2IfEntryQuery': /home/eric/work/wine/dlls/inetmib1/main.c:646:25: warning: array subscript 4294967295 is above array bounds of 'MIB_IFROW[1]' {aka 'struct _MIB_IFROW[1]'} [-Warray-bounds] 646 | &ifTable->table[tableIndex - 1], item, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /home/eric/work/wine/include/ipmib.h:21, from /home/eric/work/wine/include/iprtrmib.h:24, from /home/eric/work/wine/include/iphlpapi.h:25, from /home/eric/work/wine/dlls/inetmib1/main.c:30: /home/eric/work/wine/include/ifmib.h:66:15: note: while referencing 'table' 66 | MIB_IFROW table[1]; Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1764

3 3

[PATCH 0/1] MR978: kernelbase: Fix uninitialized return value in GetModuleHandleA().
by eric pouech (＠epo) 06 Feb '23

06 Feb '23

GCC (MingW) 12.2 rightfully warns with: /home/eric/work/wine/dlls/kernelbase/loader.c: In function 'GetModuleHandleA': /home/eric/work/wine/dlls/kernelbase/loader.c:332:12: warning: 'ret' may be used uninitialized [-Wmaybe-uninitialized] 332 | return ret; | ^~~ /home/eric/work/wine/dlls/kernelbase/loader.c:329:13: note: 'ret' declared here 329 | HMODULE ret; | ^~~ So set module to NULL on all error codepaths in GetModuleHandleExA(). Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/978

2 2

[PATCH 0/1] MR1765: krnl386.exe16: Get rid of GCC 12 warning.
by eric pouech (＠epo) 06 Feb '23

06 Feb '23

Mark args local variable with volatile to tell GCC not to check for out of bounds access. Alternative fix: use an intermediate variable to store &fun as an integer. MingW/GCC 12 complains with: In file included from /home/eric/work/wine/dlls/krnl386.exe16/thunk.c:36: /home/eric/work/wine/dlls/krnl386.exe16/thunk.c: In function 'SSCall': /home/eric/work/wine/include/wine/debug.h:91:4: warning: array subscript 1 is outside array bounds of 'INT_PTR (__attribute__((stdcall)) *[1])(void)' {aka 'int (__attribute__((stdcall)) *[1])(void)'} [-Warray-bounds] 91 | wine_dbg_log( __dbcl, __dbch, __func__, __VA_ARGS__); } } while(0) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/eric/work/wine/include/wine/debug.h:88:8: note: in expansion of macro '__WINE_DBG_LOG' 88 | __WINE_DBG_LOG | ^~~~~~~~~~~~~~ /home/eric/work/wine/include/wine/debug.h:463:36: note: in expansion of macro '__WINE_DPRINTF' 463 | #define WINE_TRACE __WINE_DPRINTF(_TRACE,__wine_dbch___default) | ^~~~~~~~~~~~~~ /home/eric/work/wine/include/wine/debug.h:506:36: note: in expansion of macro 'WINE_TRACE' 506 | #define TRACE WINE_TRACE | ^~~~~~~~~~ /home/eric/work/wine/dlls/krnl386.exe16/thunk.c:996:32: note: in expansion of macro 'TRACE' 996 | for (i = 0; i < nr/4; i++) TRACE("0x%08lx,",args[i]); | ^~~~~ /home/eric/work/wine/dlls/krnl386.exe16/thunk.c:989:17: note: at offset 4 into object 'fun' of size 4 989 | FARPROC fun, /* [in] function to call */ | ~~~~~~~~^~~ Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1765

3 3

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Timo Zuccarello (＠timozuccarello) 06 Feb '23

06 Feb '23

On Mon Feb 6 15:31:37 2023 +0000, Rémi Bernon wrote: > Yes I believe so. Is there anything I can help with? I obviously have a bit of a personal interest in having this "fixed" finally. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23088

1 0

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Rémi Bernon (＠rbernon) 06 Feb '23

06 Feb '23

On Mon Feb 6 15:28:54 2023 +0000, Timo Zuccarello wrote: > Looks great, I didn't know you were working on it already! I presume a > fixed offset is enough then in most cases, so no need for manual > mappings from XKB names? Yes I believe so. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23087

1 0

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Timo Zuccarello (＠timozuccarello) 06 Feb '23

06 Feb '23

On Mon Feb 6 15:05:02 2023 +0000, Rémi Bernon wrote: > I mean, I don't know if we need to detect VNC, but at least having an > option to enable or disable the bogus scancode auto-detect is imho a > good solution. Looks great, I didn't know you were working on it already! I presume a fixed offset is enough then in most cases, so no need for manual mappings from XKB names? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23086

1 0

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Rémi Bernon (＠rbernon) 06 Feb '23

06 Feb '23

On Mon Feb 6 15:03:35 2023 +0000, Rémi Bernon wrote: > I think it's a good way to fix this, and I started implementing the > `winecfg` option, with a first MR for some preparatory work here: https://gitlab.winehq.org/wine/wine/-/merge_requests/2062 I mean, I don't know if we need to detect VNC, but at least having an option to enable or disable the bogus scancode auto-detect is imho a good solution. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23085

1 0

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Rémi Bernon (＠rbernon) 06 Feb '23

06 Feb '23

On Mon Feb 6 14:32:23 2023 +0000, Timo Zuccarello wrote: > @rbernon Prompted by someone who also had issues with exotic or > non-qwerty keyboard layouts in #winehq, I've taken another look at this. > Came across a StackOverflow post about detecting whether a display is > VNC > (https://stackoverflow.com/questions/29371717/linux-detecting-if-youre-runni…). > Would that be an option? I.e. add an override winecfg option and by > default try to detect a VNC session and if it's VNC, use previous > mapping/code, otherwise use XKB? I think it's a good way to fix this, and I started implementing the `winecfg` option, with a first MR for some preparatory work here: https://gitlab.winehq.org/wine/wine/-/merge_requests/2062 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23083

1 0

[PATCH 0/1] MR80: vkd3d-shader/hlsl: Support reflect() intrinsic.
by Nikolay Sivov (＠nsivov) 06 Feb '23

06 Feb '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/80

3 4

Re: [PATCH 0/1] MR182: winex11: Use XKB key names to map key codes to scan codes.
by Timo Zuccarello (＠timozuccarello) 06 Feb '23

06 Feb '23

On Thu Oct 6 11:55:45 2022 +0000, Timo Zuccarello wrote: > I just went through the email thread (I'm still new to navigating > pipermail/mailing list archives) and I see the point, although I don't > think I can entirely grasp what VNC does. But the way I understand it is > that even if we used XKB names for the scan codes as in this MR, those > would be messed up just as well when using a VNC X server, as it maps > backwards from vkeys to scan codes? > In the XKB specification/documentation, "The key name links keys with > similar functions or in similar positions on keyboards that report > different scan codes", which gets me wondering how Windows actually > handles exotic keyboards or rather what is common practice in the > drivers for said exotic keyboards. > In any case, I agree, I suppose optional layout detection would be the > most compatible solution for now at least. @rbernon Prompted by someone who also had issues with exotic or non-qwerty keyboard layouts in #winehq, I've taken another look at this. Came across a StackOverflow post about detecting whether a display is VNC (https://stackoverflow.com/questions/29371717/linux-detecting-if-youre-runni…). Would that be an option? I.e. add an override winecfg option and by default try to detect a VNC session and if it's VNC, use previous mapping/code, otherwise use XKB? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23078

1 0

[PATCH 0/1] MR82: vkd3d: Fix checking for failure from SleepConditionVariableCS().
by Zebediah Figura (＠zfigura) 06 Feb '23

06 Feb '23

Fixes: 552926cfca64db45e9731f675c65a7214bfa6441 -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/82

4 3

[PATCH 0/1] MR83: vkd3d-shader: Initialize the parameter allocator head.
by Zebediah Figura (＠zfigura) 06 Feb '23

06 Feb '23

This fixes a memory leak. Fixes: 007f894b9493eb80091899dab971e369f1673a4f -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/83

4 3

[PATCH v6 0/4] MR1088: ntdll: Avoid calling pthread_exit on thread exit.
by Rémi Bernon (＠rbernon) 06 Feb '23

06 Feb '23

Using a dedicated exit jmpbuf and removing the need for assembly routines. When Wine handles an exception in unix code, we return to user mode by jumping to the last syscall frame. This can leave some pthread cancel cleanups registered, in the pthread internal linked list, and at the same time later overwrite the stack frame they were registered for. In the same way, jumping to the exit frame on thread exit or abort, can also leave some cleanup handlers registered for invalid stack frames. Depending on the implementation, calling pthread_exit will cause all the registered pthread cleanup handlers to be called, possibly jumping back to now overwritten stack frames and causing segmentation faults. Exiting a pthread normally, by returning from its procedure, or calling exit(0) for the main thread doesn't run pthread_exit and doesn't call cleanup handlers, avoiding that situation. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213 ### Additional note: For robustness, we should probably try to execute these cleanup handlers when unwinding the stack frames, as we would otherwise leave pthread objects in a potential problematic state (like a mutex locked, etc). It is however hard to do so when the handlers are registered from some C code: pthread C implementation is done by calling some internal pthread functions to register the handlers, and they aren't registered as standard unwind handlers. Only pthread_cancel and pthread_exit can unwind and call / unregister the C handlers, but interrupting that procedure, for instance calling setjmp / longjmp from withing our own handler isn't supported. From C++ code, pthread cleanup handlers are registered through C++ class constructors / destructors, and it would then be possible to partially unwind and call them at the same time. -- v6: ntdll: Remove now unnecessary arch-specific exit frame. ntdll: Avoid calling pthread_exit on thread exit. ntdll: Return entry and suspend from server_init_process_done. ntdll: Create a pthread for the main thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/1088

2 5

[PATCH v2 0/6] MR77: hlsl: Fixes for function definition vs declaration.
by Zebediah Figura (＠zfigura) 06 Feb '23

06 Feb '23

-- v2: vkd3d-shader/hlsl: Add functions to the global list inside the func_prototype rule. vkd3d-shader/hlsl: Use the original hlsl_ir_function_decl struct rather than allocating a new one for each definition. vkd3d-shader/hlsl: Put synthetic variables into a dummy scope. vkd3d-shader/hlsl: Add a hlsl_cleanup_semantic() helper. vkd3d-shader/hlsl: Store function parameters in an array. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/77

4 12

Re: [PATCH v5 0/8] MR66: vkd3d-shader/hlsl: Broaden resources support v2 (PART 1).
by Francisco Casas (＠fcasas) 06 Feb '23

06 Feb '23

:arrow_up: Rebased on top of current master. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/66#note_23066

1 0

[PATCH 0/1] MR78: vkd3d: Initialize image aspect for NULL SRVs.
by Matteo Bruni (＠Mystral) 06 Feb '23

06 Feb '23

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/78

3 2

[PATCH 0/1] MR2115: programs/conhost: only update font when running with a window.
by eric pouech (＠epo) 06 Feb '23

06 Feb '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54449 Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2115

3 2

[PATCH v3 0/3] MR1259: gitlab: Run some tests with nulldrv driver.
by Rémi Bernon (＠rbernon) 06 Feb '23

06 Feb '23

Allowing the job to fail to avoid failing the pipeline. Some new tests are failing with it, and some are succeeding todo_wine. -- v3: gitlab: Run user32 32-bit tests with nulldrv driver. https://gitlab.winehq.org/wine/wine/-/merge_requests/1259

2 4

[PATCH v2 0/5] MR1756: ntdll: Various performance improvements to hash_short_file_name.
by Rémi Bernon (＠rbernon) 06 Feb '23

06 Feb '23

The function is called a lot, I believe something like this would improve its performance in general. -- v2: ntdll: Lookup extension from the end in hash_short_file_name. ntdll: Use invalid char lookup table in lookup_unix_name. ntdll: Use invalid char lookup table in nt_to_unix_file_name_no_root. ntdll: Use invalid char lookup table in is_legal_8dot3_name. ntdll: Use invalid char lookup table in is_invalid_dos_char. https://gitlab.winehq.org/wine/wine/-/merge_requests/1756

2 7

2025

2024

2023

2022

wine-gitlab