- wine-gitlab - winehq.org

Re: [PATCH v3 0/2] MR2158: ntdll: Fix compile error on ARM64 macOS. - approved
by Alexandre Julliard (＠julliard) 16 Feb '23

16 Feb '23

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

1 0

Re: [PATCH v2 0/2] MR2219: dinput: Forbid acquiring for other process windows and hook foreground window threads. - approved
by Alexandre Julliard (＠julliard) 16 Feb '23

16 Feb '23

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

1 0

Re: [PATCH v3 0/1] MR2212: riched20/tests: Add context to the EM_FORMATRANGE tests. - approved
by Alexandre Julliard (＠julliard) 16 Feb '23

16 Feb '23

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

1 0

Re: [PATCH v2 0/1] MR2211: riched20/tests: Check clipboard content after destroying the editor window. - approved
by Alexandre Julliard (＠julliard) 16 Feb '23

16 Feb '23

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

1 0

Re: [PATCH v2 0/1] MR2218: apisetschema: Add ext-ms-win-networking-wlanapi-l1-1-0. - approved
by Alexandre Julliard (＠julliard) 16 Feb '23

16 Feb '23

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

1 0

Re: [PATCH v3 0/1] MR2216: msdasql: Always return affected rows if required. - approved
by Alexandre Julliard (＠julliard) 16 Feb '23

16 Feb '23

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

1 0

Re: [PATCH v5 0/2] MR2136: Msdasql call sql driver connect w - approved
by Alexandre Julliard (＠julliard) 16 Feb '23

16 Feb '23

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

1 0

Re: [PATCH v2 0/4] MR2209: uiautomationcore: Add support for a few different property IDs. - approved
by Alexandre Julliard (＠julliard) 16 Feb '23

16 Feb '23

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

1 0

[PATCH 0/5] MR98: hlsl: Matrix majority, 2023 edition.
by Zebediah Figura (＠zfigura) 16 Feb '23

16 Feb '23

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

3 10

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

16 Feb '23

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

5 7

[PATCH 0/4] MR2221: imm32/tests: Test ImmInstallIMEW with an actual IME.
by Rémi Bernon (＠rbernon) 16 Feb '23

16 Feb '23

Redirecting its calls to the test executable for easier testing and to wokaround some Windows IME caching mechanism that prevent the IME module from reloading. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2221

2 4

[PATCH v2 0/1] MR2190: winspool: Initialize nt_ppd in add_printer_driver.
by Alex Henrie (＠alexhenrie) 16 Feb '23

16 Feb '23

This prevents a bad free if RtlDosPathNameToNtPathName_U fails. I should have included this change in commit 69ea31ffb594eadb2b35c3f713d89f5488ee86f2, sorry. -- v2: winspool: Initialize nt_ppd in add_printer_driver. https://gitlab.winehq.org/wine/wine/-/merge_requests/2190

3 2

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

16 Feb '23

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

4 3

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

16 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. -- v3: mshtml: Send all readystatechange events for synchronous XHRs in IE9 mshtml: Implement synchronous XMLHttpRequest. mshtml: Add separate task list for tasks dispatching events. mshtml: Track responseText's length in XHRs and report it manually. mshtml: Track readyState in XHRs and report it manually. mshtml: Pass optional args to XMLHttpRequest.open() correctly. mshtml: Free the task after the destructor. mshtml: Use proper types for readystate_locked and readystate_pending. https://gitlab.winehq.org/wine/wine/-/merge_requests/2098

3 16

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

16 Feb '23

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

3 3

Re: [PATCH v4 0/3] MR1889: bthprops.cpl: Add BluetoothRegisterForAuthenticationEx stub.
by Huw Davies (＠huw) 16 Feb '23

16 Feb '23

Huw Davies (@huw) commented about dlls/bluetoothapis/bluetoothapis.spec: > @ stub BluetoothIsDiscoverable > @ stub BluetoothIsVersionAvailable > @ stub BluetoothRegisterForAuthentication > -@ stub BluetoothRegisterForAuthenticationEx > +@ stdcall BluetoothRegisterForAuthenticationEx(ptr ptr ptr ptr) bthprops.cpl.BluetoothRegisterForAuthenticationEx It looks like this is going the wrong way and that `bluetoothapis.dll` was introduced to be called by `bthprops.cpl`. I'd start switching the existing functions around (i.e. move the existing stubs in `bthprops.cpl` to `bluetoothapis.dll`). Once that is done you can add the new ones. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1889#note_24530

1 0

Re: [PATCH v3 0/1] MR2214: vbscript: fix compile issue with non hex after concat without space - approved
by Jacek Caban (＠jacek) 16 Feb '23

16 Feb '23

This merge request was approved by Jacek Caban. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2214

1 0

[PATCH v3 0/2] MR2168: win32u: Match second name when enum fonts.
by Keming Liang (＠Keming) 16 Feb '23

16 Feb '23

the patch can resolve the issue: https://bugs.winehq.org/show_bug.cgi?id=54483 and can also solve many crashed issue related to font(MS Shell Dlg etc.) -- v3: add font test for MS Shell Dlg when Language is Chinese. https://gitlab.winehq.org/wine/wine/-/merge_requests/2168

3 4

[PATCH v2 0/7] MR2220: Module loading in dbghelp.
by eric pouech (＠epo) 16 Feb '23

16 Feb '23

This series provides a bunch of new tests related to module management in dbghelp, and a couple of fixes: - correcting some module's name vs filename propagation - better handling in SymLoadModules when module overlaps the already loaded module(s) -- v2: dbghelp: Unload overlapping modules in SymLoadModule*(). dbghelp: Add new module at end of the process' modules list. dbghelp: Add some more tests about module handling. dbghelp: Add test for loaded modules enumeration. dbghelp: Let EnumerateLoadedModules() expose image names. dbghelp: Add tests for 'module' name in EnumLoadedModules() callback. dbghelp/tests: Test return value of SymLoadModule. https://gitlab.winehq.org/wine/wine/-/merge_requests/2220

2 8

[PATCH v3 0/2] MR2183: winecfg: Add an option to enable WinRT app dark theme.
by Mohamad Al-Jaf (＠maljaf) 16 Feb '23

16 Feb '23

This is what it looks like: **v1** ![Screenshot_20230213_212244](/uploads/14156031c91d4da29fc49ed9831b599a/Screenshot_20230213_212244.png) **v2** ![winecfg](/uploads/f610908b8ed2fbece6ef09ee5bd4d13e/winecfg.png) -- v3: winecfg: Add an option to enable WinRT app dark theme. https://gitlab.winehq.org/wine/wine/-/merge_requests/2183

3 6

[PATCH 0/10] MR2217: Separately store the internal pixel format set by WGL_WINE_pixel_format_passthrough.
by Zebediah Figura (＠zfigura) 16 Feb '23

16 Feb '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51848 SPORE creates a swapchain on a window, then destroys it, then creates a different swapchain on the same window and uses it for the rest of its lifetime. The swapchains have different GLX visuals (the details are unimportant). The effect is that the second swapchain sees the pixel format set by the first swapchain, through GetPixelFormat(), and therefore needs to set and then restore the new pixel format on every present. This results in recreating the GLX drawable twice per frame, which is extremely expensive. This patch series changes WGL_WINE_pixel_format_passthrough to only set an "internal" pixel format. The real pixel format will still be set as it is now, but GetPixelFormat() will always return 0, signalling to wined3d that the application has not set the pixel format, and therefore there is no need to restore it. As the tests show, this change also matches Windows, which does not report that a pixel format has been set after presenting a Direct3D swapchain. This is a large series by patch count, but I fear that splitting it into two parts would make it difficult to grasp the entire picture, and purpose of the earlier patches. It also contains six patches which are simply repetitions across the three user drivers, which should ease the burden of review somewhat. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2217

4 12

[PATCH 0/7] MR2220: Module loading in dbghelp.
by eric pouech (＠epo) 16 Feb '23

16 Feb '23

This series provides a bunch of new tests related to module management in dbghelp, and a couple of fixes: - correcting some module's name vs filename propagation - better handling in SymLoadModules when module overlaps the already loaded module(s) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2220

3 8

[PATCH 0/2] MR2219: dinput: Forbid acquiring for other process windows and hook foreground window threads.
by Rémi Bernon (＠rbernon) 16 Feb '23

16 Feb '23

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54431 Some out-of-tree tests seem to show that acquiring other process windows is not allowed, although hard to test that without opening the SetForegroundWindow pandora's box. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2219

2 2

[PATCH v2 0/5] MR2177: win32u: Get monitor name from EDID when possible
by Paul Gofman (＠gofman) 16 Feb '23

16 Feb '23

There are two common ways I observe how games get monitor name to display: 1. Registry key under Enum/Display (also present in EnumDisplayDevicesA result for monitors). On Windows this key is derived from edid as 'Manufacturer ID' (3 letters) combined with "Manufacturer product code" (4 hex digits). We currently have 'Default_Display' there for all the displays; 2. DisplayConfigGetDeviceInfo(DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME). Windows sets friendlyNameFromEdid flag and returns a name from 'EDID Display Descriptor' with code 0xfc ("Display name"). As far as I could see by searching through the Windows registry this name doesn't seem to be explicitly present anywhere in registry (besides binary raw edid of course). The first patch removes name from the gdi driver's display structure. Now none of the drivers set anything genuine there. x11 and winemac always end up with "Generic Non-Pnp Monitor" string, wineandroid sets NULL there and "Generic Non-Pnp Monitor" is set in win32u in this case. That "Generic Non-Pnp Monitor" goes to "DeviceDesc" registry value. While our value doesn't match Windows string exactly, Windows also doesn't have any meaningful name under DeviceDesc (and contains "Generic Non-Pnp Monitor" as a part of it). So this patch is essentially a no-op currently. Going forward my idea is that we just want to have edid from drivers. If the raw one is not available we can generate fallback one ourselves based on the info about the monitor we might have from elsewhere in the drivers. My motivation is: - EDID is sometimes queried by apps directly, and it is better to provide a true one or a synthetic one with as much of accurate info as possible / reasonable; - There is more info in EDID, e. g., colorimetry for HDR support in d3d. As far as I can tell, there is no documented way to query HDR info on Windows besides dxgi interfaces (which in case on Wine are based on gdi drivers for such things and can hardly become a genine source of such info in Wine) and WinRT interface (for which I don't know where it takes the info on Windows but we probably don't want to make it a lower level source of such info in Wine). The alternative would be, instead of basing higher level win32u on EDID, parse EDID in drivers instead and add all the necessary info into gdi_monitor structure (instead of removing display name from there), but so far it seems less straightforward to me. -- v2: win32u: Get friendly monitor name from EDID in NtUserDisplayConfigGetDeviceInfo(). win32u: Return edidManufactureId and edidProductCodeId from NtUserDisplayConfigGetDeviceInfo(). win32u: Store EDID in monitors cache. win32u: Use monitor ID from EDID when available. win32u: Remove monitor name from gdi driver monitor info. https://gitlab.winehq.org/wine/wine/-/merge_requests/2177

3 9

[PATCH v2 0/1] MR2212: riched20/tests: Add context to the EM_FORMATRANGE tests.
by Francois Gouget (＠fgouget) 16 Feb '23

16 Feb '23

-- v2: riched20/tests: Add context to the EM_FORMATRANGE tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/2212

4 6

2025

2024

2023

2022

wine-gitlab