Needed to prevent VR games from crashing when the user attempts to capture the desktop.
The reference count seems to start at 0, which I've never encountered before. Not sure if my code is incorrect.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2490
This corrects what interface should be returned, there isn't a hierarchy with
these IUISettings at all. It should return IUISettings and then QI for
any others that it requires.
--
v6: windows.ui: Use DEFINE_IINSPECTABLE for IUISettings3
windows.ui: Add IUISettings2 stub interface
windows.ui: Add Stubbed interface IUISettings
include: Add Missing IUISettings interfaces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2465
This corrects what interface should be returned, there isn't a hierarchy with
these IUISettings at all. It should return IUISettings and then QI for
any others that it requires.
--
v5: windows.ui: Use DEFINE_IINSPECTABLE for IUISettings3
windows.ui: Add IUISettings2 stub interface
windows.ui: Add Stubbed interface IUISettings
include: Add Missing IUISettings interfaces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2465
This corrects what interface should be returned, there isn't a hierarchy with
these IUISettings at all. It should return IUISettings and then QI for
any others that it requires.
--
v4: windows.ui: Use DEFINE_IINSPECTABLE for IUISettings3
windows.ui: Add IUISettings2 stub interface
windows.ui: Add Stubbed interface IUISettings
include: Add Missing IUISettings interfaces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2465
CertOpenStore(CERT_STORE_PROV_SYSTEM_REGISTRY_, ..., "Root") is taking 80-250ms here when executed first time in a process. That triggers a race condition in some CEF / NWJS games (Purgo box is an example), where NWJS seems to depend on main thread initialization going faster than 3d initialization in the other thread (otherwise it crashes). The main hitter is the mentioned CertOpenStore(). Probably more important is that the delay is always there upon first time reading root certs per process start which happens, e. g., any time an app wants to establish a seure connection to public server.
The major hitter is rootstore.c:check_and_store_certs() which validates certificate chains as a part of host certificate import which is always done fully.
The idea is that we can persist registry cache (which load is relatively quick) only adding a new certificates, also making sure that none of the previously root certs was deleted. In the latter case the patches fallback to full reimport to guarantee that the chain validation is not affected.
The patchset brings CertOpenStore(CERT_STORE_PROV_SYSTEM_REGISTRY_, ..., "Root") time from 80-250ms to 5-10ms here after the registry cache was filled once and no cert was deleted on host. The full reinitialization time (on clean prefix or when a cert was deleted) stays nearly the same.
Patch 2 introduces a relatively small independent optimization (which avoids searching for certificate in store when it was needed). It has much lesser impact on the overall process (a few ms here) but is also much simplier.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2488
On Fri Mar 24 02:49:18 2023 +0000, Nikolay Sivov wrote:
> For commit message it's better to have some description message, and not
> duplicating what code actually does.
I have just updated my commit message and you can review it again.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2413#note_27721
Removing WINED3D_RS entries from state tables and moving stubs to wined3d_device_apply_stateblock.
--
v4: wined3d: Move the WINED3D_RS_ENABLEADAPTIVETESSELLATION stub to wined3d_device_apply_stateblock.
wined3d: Move the WINED3D_RS_ADAPTIVETESS_W stub to wined3d_device_apply_stateblock.
wined3d: Move the WINED3D_RS_ADAPTIVETESS_Z stub to wined3d_device_apply_stateblock.
wined3d: Move the WINED3D_RS_ADAPTIVETESS_Y stub to wined3d_device_apply_stateblock.
wined3d: Move the WINED3D_RS_ADAPTIVETESS_X stub to wined3d_device_apply_stateblock.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2469
Without this patch the process will silently die.
I managed to trigger this while trying to trace Child of Light with Renderdoc,
the latter of which crashed in its own "TargetControlServerThread".
This, confusingly, manifested in the game restarting itself without the Ubisoft
overlay; apparently the game or one of its launchers was capable of recognizing
when the process had died and restarting it, but would not try to inject the
overlay a second time. I have not investigated the cause of the crash; it is not
unlikely that it resulted from the overlay injection (despite the fact that that
should only directly affect PE code.)
--
v5: ntdll: Print an error if we receive a signal not on the signal stack.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2126
> Only if you accept that it overflows above the install button, I'm not sure that's better.
You're right, it does overflow with some of the translations.
This seems like the safest way to add it:

I checked the longest `Install theme` translation, which is Lithuanian, and it doesn't overflow:

Alternatively, the `Color` combo box could be moved to the first row like so:

Which of these would be most preferable? I'm leaning towards the second one.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2183#note_27712
This node type is intended for use during parse-time.
While we parse an indexing expression such as `a[3]`, we don't know if
it will end up as part of an expression (in which case it must be folded
into a load) or it is for the lhs of a store (in which case it must be
folded into the store's deref). This node type is used to represent these accesses and no longer rely on building an `hlsl_ir_load` for each array index or struct record access.
`hlsl_ir_index` chains are lowered into derefs when (and if) they are used to specify the lhs of an assignment. All `hlsl_ir_index`es are lowered into `hlsl_ir_load`s with a compilation pass.
The changes introduced in these series allow to solve the problem with the return variable of function calls presented in !93, and to properly support assignment to matrix indexes, which is something we are not doing correctly.
Further patches (in my [index node](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/index_node) branch) add support for indexing non-load expressions, such as `(a + b)[1]` and allowing to represent resource loads through `hlsl_ir_index`, so that `hlsl_ir_resource_store`s don't have to rely on `hlsl_ir_resource_load`s.
--
v3: vkd3d-shader/hlsl: Copy index chain values into synthetic vars.
tests: Test indexing of non-loads.
vkd3d-shader/hlsl: Support column-major matrix indexing in the lhs.
vkd3d-shader/hlsl: Always load from a synthetic copy in add_load_component().
vkd3d-shader/hlsl: Remove add_load_index().
vkd3d-shader/hlsl: Use hlsl_ir_index for array and record access.
vkd3d-shader/hlsl: Introduce hlsl_ir_index.
tests: Test side effects on indexes.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/124
--
v8: winegstreamer: Implement ProcessInput and ProcessOutput for WMV decoder DMO.
winegstreamer: Create wg_transform for WMV decoder.
winegstreamer: Ignore framerate of media type for WMV decoder DMO.
winegstreamer: Add format field to wmv wg_format.
mf/tests: Test time length returned by ProcessOutput.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2258
This node type is intended for use during parse-time.
While we parse an indexing expression such as `a[3]`, we don't know if
it will end up as part of an expression (in which case it must be folded
into a load) or it is for the lhs of a store (in which case it must be
folded into the store's deref). This node type is used to represent these accesses and no longer rely on building an `hlsl_ir_load` for each array index or struct record access.
`hlsl_ir_index` chains are lowered into derefs when (and if) they are used to specify the lhs of an assignment. All `hlsl_ir_index`es are lowered into `hlsl_ir_load`s with a compilation pass.
The changes introduced in these series allow to solve the problem with the return variable of function calls presented in !93, and to properly support assignment to matrix indexes, which is something we are not doing correctly.
Further patches (in my [index node](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/index_node) branch) add support for indexing non-load expressions, such as `(a + b)[1]` and allowing to represent resource loads through `hlsl_ir_index`, so that `hlsl_ir_resource_store`s don't have to rely on `hlsl_ir_resource_load`s.
--
v2: vkd3d-shader/hlsl: Support matrix indexing in the lhs.
vkd3d-shader/hlsl: Always load from a synthetic copy in add_load_component().
vkd3d-shader/hlsl: Remove add_load_index().
vkd3d-shader/hlsl: Use hlsl_ir_index for array and record access.
vkd3d-shader/hlsl: Introduce hlsl_ir_index.
tests: Test matrix indexing on the lhs.
tests: Test multiple calls to the same function in initializers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/124
This concludes the series.
--
v2: ddraw: Reimplement SetSurfaceDesc() by recreating the wined3d texture(s).
wined3d: Pass parent ops to wined3d_rendertarget_view_set_parent().
ddraw/tests: Add some tests for creating surfaces with user memory.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2480
Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826).
--
v19: ntdll: Set xattr in NtCreateFile if inferred and requested attributes don't match.
ntdll: Only infer hidden attribute from file name if xattr is not present.
ntdll: Handle hidden file names inside get_file_info instead of after it.
ntdll: Do not open-code hidden file handling in get_dir_data_entry.
ntdll/tests: Add test for file attributes of files with names beginning with a dot.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1148
Removing WINED3D_RS entries from state tables and moving stubs to wined3d_device_apply_stateblock.
--
v3: wined3d: Move the WINED3D_RS_ENABLEADAPTIVETESSELLATION stub to wined3d_device_apply_stateblock.
wined3d: Move the WINED3D_RS_ADAPTIVETESS_W stub to wined3d_device_apply_stateblock.
wined3d: Move the WINED3D_RS_ADAPTIVETESS_Z stub to wined3d_device_apply_stateblock.
wined3d: Move the WINED3D_RS_ADAPTIVETESS_Y stub to wined3d_device_apply_stateblock.
wined3d: Move the WINED3D_RS_ADAPTIVETESS_X stub to wined3d_device_apply_stateblock.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2469
On Thu Mar 23 19:32:06 2023 +0000, Brendan Shanks wrote:
> I suggested the drop-down, a future third option would be to use the
> host system's light/dark mode setting
Yeah, a check mark was what I initially went with, but there's concern about the translations. Some of them can be quite long and would likely overflow into other elements.
The text has to be explicit enough to not confuse the user, something like `Enable WinRT app dark theme`, which is quite long as it is. But in other languages, it can be even longer.
For instance, in French, this can translate to `Activer le thème sombre de l'application WinRT`. In Greek, `Ενεργοποιήστε το σκοτεινό θέμα της εφαρμογής WinRT`. The Greek translation would most likely overflow.
The check mark would need to be on its own row to prevent this issue, but there doesn't seem to be enough space to add one.
I'm open to suggestions. However, a drop-down eliminates the overflow issue altogether.
Also, some people want an option to use the host system's mode, but I don't know if this is something that Wine would support.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2183#note_27659
On Thu Mar 23 19:32:06 2023 +0000, Alexandre Julliard wrote:
> > How's this?
> >
> > Thanks for the review! :smiley:
> Actually thinking some more about this, a simple check mark may be
> better than a drop-down. It's not like there would be other possible options.
I suggested the drop-down, a future third option would be to use the host system's light/dark mode setting
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2183#note_27658
### Merge request
This fixes a vulnerability by incorrect parsing of command line arguments.
The way how a triple quote chars (or double quote chars inside a quoted string) will be currently parsed in `CommandLineToArgvW` of wine is wrong, therefore opens an attack vector (using artificially created command line validated with different rules matching default parsing mechanism of Windows), so could be even considered as a vulnerability.
## Proposed changes
`CommandLineToArgvW` will parse command line arguments correct and more similar to Windows.
Here is the diff illustrating wrong behavior:
```diff
## # test is an alias for
## # python.exe -c "from sys import argv; del argv[0]; print(str(len(argv)) + ' | ' + ' | '.join(argv))"
- # Wine
+ # Windows (and fixed variant)
## double in quoted string:
> test "abc""def" ghi" xxx
- 2 | abc"def ghi | xxx
+ 2 | abc"def | ghi xxx
> test "abc"""def" ghi" xxx
- 3 | abc"def | ghi" xxx
+ 2 | abc"def ghi | xxx
## triple in unquoted string:
> test abc"""def" ghi" xxx
- 2 | abc"def ghi | xxx
+ 2 | abc"def | ghi xxx
> test abc""""def" ghi" xxx
- 2 | abc"def | ghi xxx
+ 2 | abc"def ghi | xxx
```
As a consequence:
- the arguments can be parsed incorrectly (compared to default behavior of Windows parser) in the way that parts of quoted arguments may become unquoted and vice versa, as well as swim between different args;
- an attacker may create artificial command line that pass validation rules of nominal condition of Windows, but vulnerable here (inject, data steal, etc), because the arguments would deviate between validation and execution phase
- special tokens like pipe `|`, ampersand `&` or redirecting tokens like `>` that normally included in quoted string (and validated as a string) could abrupt get different meaning and used for piping, redirecting etc, that beside the injection possibility opens still worse attacking vector that can even cause RCE or used to create persistent exploits.
<details><summary>Here is the nominal condition how arguments will be parsed in Windows...</summary>
cmd line|arg1|arg2
---|---|---
abc" "def|abc def|
abc\\" \\"def|abc"|"def
"abc\\" \\"def"|abc" "def|
"abc"" ""def"|abc" "def|
abc"" ""def|abc|def
abc""" """def|abc" "def|
abc\\""" \\"""def|abc"|"def
abc\\\\""" \\\\"""def|abc\\" \\"def
"abc"""def" ghi"</sup>|abc"def ghi|
"abc"""def" ghi<br><sup>* missing close qoute at end</sup>|abc"def ghi|
"abc""def" ghi|abc"def|ghi
"abc\\"""def" ghi|abc""def|ghi
"abc\\\\"""def" ghi"|abc\\"def ghi|
"abc\\\\\\"""def" ghi|abc\\""def|ghi
"abc\\\\\\\\"""def" ghi"|abc\\\\"def ghi|
</details>
For PoC one could use any lang like tcl, python, etc, or even a self-written executable getting the argc/argv from main.<br/>
The above diff and nominal condition was generated using this python script on Windows box:
```python
from sys import argv; del argv[0]; print(str(len(argv)) + ' | ' + ' | '.join(argv))
```
## References
[Related PR](https://github.com/reactos/reactos/pull/5186) with fix for ReactOS.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2472
This second MR in the Wayland series adds display configuration related enhancements, including providing more display information (like a proper/consistent name and position) to Wine and implementing GetCurrentDisplaySettings.
To get additional information from the Wayland compositor we need to use a protocol from the wayland-protocols collection, so we introduce support in the build system for protocol .xml files, and also makedep changes to gracefully handle the case these external sources are missing when the driver is disabled. These changes are introduced on their own in the first commit in the series, but we can squash it with the next commit, where the functionality is first used, if preferred.
To be able to provide a consistent view of the display settings across all processes, this MR adds a shared memory region containing an authoritative version of the Wayland output information (see the "winewayland.drv: Implement GetCurrentDisplaySettings." commit for more details).
**Important note:** This MR requires the wayland-protocols package in the CI docker image. Without it the Wayland driver build will be disabled, so any build results are not going to be representative of the Wayland driver code changes in this branch.
Thanks!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2476
On Windows, ldap_delete_(ext_)s returns LDAP_UNWILLING_TO_PERFORM when
trying to delete an entry that cannot be deleted. On Unix,
LDAP_SERVER_DOWN is returned instead. Unix also returns LDAP_SERVER_DOWN
immediately from ldap_delete_ext if the entry cannot be deleted, whereas
Windows queues an asynchronous operation and returns LDAP_SUCCESS.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54702
--
v2: wldap32: Handle null DN or null message in ldap_delete* and add tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2481
I initially wanted to do the refactoring in a separate merge request, but since my merge request yesterday broke the tests, I decided to add the implementation into this commit as well.
--
v2: kernelbase: Recursively obtain the Wow6432Node parent.
kernelbase: Add support for shared registry keys.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2483
I initially wanted to do the refactoring in a separate merge request, but since my merge request yesterday broke the tests, I decided to add the implementation into this commit as well.
--
v3: kernelbase: Recursively obtain the Wow6432Node parent.
kernelbase: Add support for shared registry keys.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2483
--
v2: wineps: Handle EMR_LINETO record in spool files.
wineps: Handle EMR_MOVETOEX record in spool files.
wineps: Handle EMR_RECTANGLE record in spool files.
wineps: Handle pen selection in spool files.
wineps: Handle brush selection in spool files.
wineps: Handle EMR_EOF record in spool files.
wineps: Handle EMR_HEADER record in spool files.
wineps: Write document header and footer in PrintDocumentOnPrintProcessor.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2484
This is what it looks like:

--
v9: winecfg: Add an option to set WinRT app dark theme.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2183
This corrects what interface should be returned, there isn't a hierarchy with
these IUISettings at all. It should return IUISettings and then QI for
any others that it requires.
--
v3: windows.ui: Use DEFINE_IINSPECTABLE for IUISettings3
windows.ui: Add IUISettings2 stub interface
windows.ui: Add Stubbed interface IUISettings
include: Add Missing IUISettings interfaces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2465
On Windows, ldap_delete_(ext_)s returns LDAP_UNWILLING_TO_PERFORM when
trying to delete an entry that cannot be deleted. On Unix,
LDAP_SERVER_DOWN is returned instead. Unix also returns LDAP_SERVER_DOWN
immediately from ldap_delete_ext if the entry cannot be deleted, whereas
Windows queues an asynchronous operation and returns LDAP_SUCCESS.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54702
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2481
--
v7: winegstreamer: Implement ProcessInput and ProcessOutput for WMV decoder DMO.
winegstreamer: Create wg_transform for WMV decoder.
winegstreamer: Better handle framerate.
winegstreamer: Add format field to wmv wg_format.
mf/tests: Test time length returned by ProcessOutput.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2258
On Thu Mar 16 16:04:48 2023 +0000, Gabriel Ivăncescu wrote:
> I think they're still useful, since they're the only "movable" devices
> (in PA Volume Control for example). They use the largest channel mask
> out of all the sources/sinks, so it's not a problem to have them movable
> with no notifications to the app, unlike the others.
How should we proceed then?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2364#note_27595
The app I'm considering opens a video_processor on its own, with
a NV12 format on input and a ARGB32 format on output.
Tested on Windows: the samples are flipped vertically. While Wine
keeps them untouched.
So added a videoflip in the video processor to be activated when needed.
Current activation is based on RGB vs non RGB input/output formats.
Set as draft as if somehow related to MR!2159.
Comments welcomed.
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2471
wine-gecko started calling dwmapi since dwmapi stubs were improved between Wine 7 and 8. It loops in gfxWindowsPlatform.cpp:VBlankLoop() in a tight loop now because DwmFlush() is a no-op. Besides unneeded CPU load that also causes hangs on exit in Final Fantasy XIV launcher. The launcher can't get WM_QUIT message in its message loop because it constantly gets the messages queued from VBlankLoop() while processing previous "nsAppShell:EventID" message.
DwmFlush() is supposed to wait until next VBlank. My supplied test only tests that the wait is not alertable, but I also ad-hoc tested that the delay time introduced by DmwFlush() is between 0 and display refresh frequency.
--
v2: dwmapi: Sleep in DwmFlush().
https://gitlab.winehq.org/wine/wine/-/merge_requests/2463
wine-gecko started calling dwmapi since dwmapi stubs were improved between Wine 7 and 8. It loops in gfxWindowsPlatform.cpp:VBlankLoop() in a tight loop now because DwmFlush() is a no-op. Besides unneeded CPU load that also causes hangs on exit in Final Fantasy XIV launcher. The launcher can't get WM_QUIT message in its message loop because it constantly gets the messages queued from VBlankLoop() while processing previous "nsAppShell:EventID" message.
DwmFlush() is supposed to wait until next VBlank. My supplied test only tests that the wait is not alertable, but I also ad-hoc tested that the delay time introduced by DmwFlush() is between 0 and display refresh frequency.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2463
Diablo IV (closed beta) depends on DEVPKEY_Device_MatchingDeviceId being present for GPUs (once it is able to match GPU luid to the one obtained from dxgi). It also depends on the MatchingDeviceId conating "ven_" and "dev_" substrings. Without those it doesn't consider the gpu as valid, which currently results in the game complaining about no GPUs found. I guess that maybe it is trying to filter out software GPUs and such this way.
As far as my testing goes, DEVPKEY_Device_MatchingDeviceId has this form with hardware GPUs only and maybe with the recent enough Win10 or Win11.
The other two device properties being added are also queried by the game although they are not strictly needed for it.
--
v4: win32u: Set DEVPKEY_Device_RemovalPolicy for GPUs.
win32u: Set DEVPKEY_Device_BusNumber for GPUs.
win32u: Set DEVPKEY_Device_MatchingDeviceId for GPUs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2449
This corrects what interface should be returned, there isn't a hierarchy with
these IUISettings at all. It should return IUISettings and then QI for
any others that it requires.
--
v2: windows.ui: Use DEFINE_IINSPECTABLE for IUISettings3
windows.ui: Add IUISettings2 stub interface
windows.ui: Add Stubbed interface IUISettings
include: Add Missing IUISettings interfaces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2465
This is what it looks like:

--
v8: winecfg: Add an option to set WinRT app dark theme.
wine.inf: Add AppsUseLightTheme key.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2183
There is one more patch series of refactoring create_key() after this one, then I can start implementing things.
--
v3: kernelbase: Return the last existing key from open_key() when it's called from create_key().
kernelbase: Pass a name pointer to open_key().
kernelbase: Use open_key() to obtain any existing Wow6432node in create_key().
kernelbase: Call open_key() from open_subkey().
https://gitlab.winehq.org/wine/wine/-/merge_requests/2445
This corrects what interface should be returned, there isn't a hierarchy with
these IUISettings at all. It should return IUISettings and then QI for
any others that it requires.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2465
Diablo IV (closed beta) depends on DEVPKEY_Device_MatchingDeviceId being present for GPUs (once it is able to match GPU luid to the one obtained from dxgi). It also depends on the MatchingDeviceId conating "ven_" and "dev_" substrings. Without those it doesn't consider the gpu as valid, which currently results in the game complaining about no GPUs found. I guess that maybe it is trying to filter out software GPUs and such this way.
As far as my testing goes, DEVPKEY_Device_MatchingDeviceId has this form with hardware GPUs only and maybe with the recent enough Win10 or Win11.
The other two device properties being added are also queried by the game although they are not strictly needed for it.
--
v3: win32u: Set DEVPKEY_Device_RemovalPolicy for GPUs.
win32u: Set DEVPKEY_Device_BusNumber for GPUs.
win32u: Set DEVPKEY_Device_MatchingDeviceId for GPUs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2449