Fixes Starfield not being able to take photos in photo mode (due to failing to creating windowscodecs' image factory due to COM apartment being initialized). Turns out on Windows RoGetActivationFactory() initializes implicit MTA apartment when called from STA thread, and so after that called once COM is implicitly uninitialized for any (new) thread until COM is uninitialized in the thread which called RoGetActivationFactory (or that thread exited). This is not the case on Win8 (where the function was first introduced) but looks consistent after that.
--
v2: combase: Create implicit MTA in STA apartment in RoGetActivationFactory().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3806
--
v2: gdiplus: Include the newline in the measurement of each line.
gdiplus/tests: Add test for bounds of newline.
win32u: Detect and handle characters that are considered to have no width for GetTextExtentExPoint.
gdi32/tests: Add test for width of carriage return and line feed.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3517
`FileRenameInformationEx` and `FileLinkInformationEx` are expanded versions of the `FileRenameInformation` and `FileLinkInformation` classes in `NtSetInformationFile`. They replace a single `ReplaceIfExists` flag with a `Flags` field that can contain a wider selection of options.
This patch-set implements these new classes by replacing the `replace` field of the `set_fd_name_info` server request with `flags`. The original `FileRenameInformation` and `FileLinkInformation` classes are then reimplemented to use `FILE_RENAME_REPLACE_IF_EXISTS` and `FILE_LINK_REPLACE_IF_EXISTS` respectively.
The patch set additionally implements `FILE_RENAME_IGNORE_READONLY_ATTRIBUTE` and `FILE_LINK_IGNORE_READONLY_ATTRIBUTE`, as well as `FILE_RENAME_POSIX_SEMANTICS` and `FILE_LINK_POSIX_SEMANTICS`.
Wine Bugs:
* [#54997](https://bugs.winehq.org/show_bug.cgi?id=54997) - msys2: gpg.exe fails because "NtSetInformationFile Unsupported class (65)" / FileRenameInformationEx
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3816
In `Makefile`, `foobar.tab.c` is made from the following rules:
```
foobar.tab.h: foobar.y
bison -o foobar.tab.c -d foobar.y ---- Rule X
foobar.tab.c: foobar.y foobar.tab.h
bison -o $@ foobar.y --- Rule Y
```
Normally, `Rule X` is used. In parallel makes, if `foobar.tab.c` is
considered while updating `foobar.tab.h` by `Rule X`, `Rule Y` is used.
So, if we compare build directories, there might be a difference in that
`foobar.tab.c` may or may not contain `#include "foobar.tab.h"`.
To avoid the above situation, this patch introduces [Grouped Targets](https://www.gnu.org/software/make/manual/html_node/Multiple-Target… which is
new in GNU Make 4.3.
The previous rules still apply to prevent build failures on older
systems, such as Ubuntu 20.04 LTS.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3797
--
v2: tests: Compile HLSL shaders at runtime in test_unknown_dsv_format().
tests: Compile HLSL shaders at runtime in test_unknown_rtv_format().
tests: Compile HLSL shaders at runtime in test_multiple_render_targets().
tests: Compile HLSL shaders at runtime in test_create_compute_pipeline_state().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/337
This goes on top of !325 (which was already approved).
--
v4: include: Add some misc D3D12 structs/enums/macros.
include: Add some D3D12 raytracing specific structs.
include: Add the D3D12_BARRIER_GROUP struct.
include: Add the ID3D12Tools interface.
include: Add the ID3D12VirtualizationGuestDevice interface.
include: Add the ID3D12Device10 interface.
include: Add the ID3D12Device9 interface.
include: Add the ID3D12ShaderCacheSession interface.
include: Add the ID3D12GraphicsCommandList4 interface.
include: Add the ID3D12MetaCommand interface.
include: Add the ID3D12Heap1 interface.
include: Add the ID3D12Resource{1,2} interfaces.
include: Add the ID3D12Device8 interface.
include: Add the structs D3D12_FEATURE_DATA_D3D12_OPTIONS{6,7}.
include: Add the ID3D12Device7 interface.
include: Add the ID3D12ProtectedResourceSession1 interface.
include: Add the ID3D12Device6 interface.
include: Add the ID3D12DeviceRemovedExtendedData{,1,2} interfaces.
include: Add the ID3D12DeviceRemovedExtendedDataSettings{,1} interfaces.
include: Add the ID3D12Device5 interface.
include: Add the ID3D12StateObjectProperties interface.
include: Add the ID3D12StateObject interface.
include: Add the ID3D12LifetimeTracker interface.
include: Add the ID3D12SwapChainAssistant interface.
include: Add the ID3D12LifetimeOwner interface.
include: Add the ID3D12Device4 interface.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/332
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v4: vkd3d-shader/hlsl: Add constant folding for the ternary operator.
vkd3d-shader/hlsl: Use conditional moves for arithmetic operators instead of branching.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/336
I wanted to use ._xy element access to make it shorter, but that attempt was crushed by the reality - such indexing apparently compiles but does not produce correct element access loads. I'm going to update once this is fixed.
--
v5: vkd3d-shader/hlsl: Add determinant() function.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/329
Fixes Starfield not being able to take photos in photo mode (due to failing to creating windowscodecs' image factory due to COM apartment being initialized). Turns out on Windows RoGetActivationFactory() initializes implicit MTA apartment when called from STA thread, and so after that called once COM is implicitly uninitialized for any (new) thread until COM is uninitialized in the thread which called RoGetActivationFactory (or that thread exited). This is not the case on Win8 (where the function was first introduced) but looks consistent after that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3806
And discard irrelevant parts in select request. We currently store something in CTX_PENDING and ignore it later in select request if we're currently running in wow context.
--
v6: ntdll/tests: Add tests for setting context on unsuspended thread.
server: Store both contexts in pending context object.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3566
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v10: kernelbase: Check for PERF_SIZE_LARGE in PerfSetULongLongCounterValue and PerfSetULongCounterValue
kernelbase : Check for PERF_ATTRIB_BY_REFERENCE attribute in PerfSetCounterRefValue
advapi/test: Add Test For PerfSetULongLongCounterValue
advapi32/tests: Create Tests for PerfSetULongCounterValue
advapi32: Forward PerfSetULongCounterValue and PerfSetULongLongCounterValue to kernelbase
kernelbase: Add implementation for PerfSetULongLongCounterValue
kernelbase: Add implementation of PerfSetULongCounterValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
> it's necessary to cast the pointers returned from malloc and realloc here because we add 1 to the pointer before assigning it to a variable. It's unusual but it works. Still, we could simplify this code a bit by only calling realloc.
Right, sorry about that.
However, let's start off with a commit that makes this explicit, to avoid mistakes by future reviewers. Something like:
```c
if (llTypes[type].lpMlds) {
WINE_MLD *mem = llTypes[type].lpMlds - 1;
mem = HeapReAlloc(GetProcessHeap(), 0, mem, sizeof(WINE_MLD) * (llTypes[type].wMaxId + 1));
llTypes[type].lpMlds = mem + 1;
} else {
WINE_MLD *mem;
mem = HeapAlloc(GetProcessHeap(), 0, sizeof(WINE_MLD) * (llTypes[type].wMaxId + 1));
llTypes[type].lpMlds = mem + 1;
}
```
Then we can merge to two branches into `realloc()` in the commit that switches things to the CRT allocator.
> As far as the casts in the calls to free, they are all to avoid warnings about freeing pointers to const strings, so they can't be removed.
Got it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3736#note_45151
Adds the tray icons implementation based on org.kde.StatusNotifierItem interface usage. Does allow restarting StatusNotifierWatcher object, but will fallback to XEMBED or internal tray, if wine gets initialized when there is no StatusNotifierWatcher object registered.
--
v24: winesni.drv: add dbus watch instead of using plain unix fds and flush
winesni.drv: replaced the dbus connection logic with a single connection per each SNI object
winesni.drv: wrap functions with pthread mutex locking
winesni.drv: implement basic balloon notification support
explorer: add winesni.drv tray implementation support
winesni.drv: add KDE StatusNotifierItem implementation for tray
https://gitlab.winehq.org/wine/wine/-/merge_requests/2808
It's possible that a state object pointer not in the topology node collection gets passed to
session_get_node_object(). Instead of returning the last node when the object is not found, we
should return a NULL so that the state of the last node is not changed by mistake.
--
v6: mf/tests: Test IMFMediaSession::Start().
mf/tests: Add a create_media_session() helper.
mf: Add seeking support for IMFMediaSession::Start().
mf: Add a session_flush_nodes() helper.
mf: Make session_get_node_object() more robust.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3572
On Wed Sep 13 02:57:29 2023 +0000, Alex Henrie wrote:
> You're right that it's unnecessary to cast the void pointer returned
> from malloc or realloc, so I've removed those casts. Thanks for pointing
> that out. As far as the casts in the calls to free, they are all to
> avoid warnings about freeing pointers to const strings, so they can't be removed.
No, never mind, it's necessary to cast the pointers returned from malloc and realloc here because we add 1 to the pointer before assigning it to a variable. It's unusual but it works. Still, we could simplify this code a bit by only calling realloc.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3736#note_45138
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v9: kernelbase: Check for PERF_SIZE_LARGE in PerfSetULongLongCounterValue and PerfSetULongCounterValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v7: kernelbase: Check for PERF_SIZE_DWORD and PERF_SIZE_LARGE in PerfSetULongLongCounterValue and PerfSetULongCounterValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
As @nsivov pointed out, we are currently parsing matrix swizzles (e.g. mat._m12_m32) and creating an hlsl_ir_swizzle for the matrix itself. We are currently allowing shaders that use these to compile even though they are not working.
While our compilation passes don't expect hlsl_ir_swizzles with matrix values, turns out we need them as a parse-time construct because we don't know if they will be used as the lhs of an assignment during parsing, similarly to hlsl_ir_indexes.
This patch adds tests and a pass to lower these matrix swizzles.
Implementing assignments with matrix swizzles is still pending.
--
v2: vkd3d-shader/hlsl: Lower matrix swizzles.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/331
The validation code is meant both as a check that the frontend is behaving properly and as a sort of the documentation to establish what is allowed and what is not in the IR.
~~Currently an assertion is thrown if validation fails. I realize this is a rather strong proposal, but it's of course up for debate. In theory asserting here is the right thing, as it is expected that the frontend is generating correct IR code. However vkd3d is already used in production for many programs, and it could very well be that some of those are working properly even if the generated IR is somewhat out of specs; allowing the assertion might cause regressions as soon as enough checks are implemented in the validator. Please let me know your opinions.~~ **Solved in favor of a softer failure, and only when validation is enabled**
--
v8: vkd3d-shader/ir: Validate source parameters.
vkd3d-shader/ir: Validate destination parameters.
vkd3d-shader/ir: Validate register types.
vkd3d-shader/ir: Validate instruction handlers.
vkd3d-shader/ir: Introduce a boilerplate to validate the generated IR.
vkd3d-shader: Embed the parsing location in vkd3d_shader_instruction.
vkd3d-shader/dxil: Destroy the SM6 parser on parsing errors.
vkd3d-shader/tpf: Destroy the SM4 parser on parsing errors.
vkd3d-shader/d3dbc: Destroy the SM1 parser on parsing errors.
vkd3d-shader/d3dbc: Skip DCL semantic tokens properly.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/317
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v6: kernelbase: Check for PERF_SIZE_DWORD and PERF_SIZE_LARGE in PerfSetULongLongCounterValue and PerfSetULongCounterValue
kernelbase : Check for PERF_ATTRIB_BY_REFERENCE attribute in PerfSetCounterRefValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v4: advapi32/tests: Create Tests for PerfSetULongCounterValue and PerfSetULongLongCounterValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v5: advapi32/tests: Create Tests for PerfSetULongCounterValue and PerfSetULongLongCounterValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v3: advapi32/tests: Create Tests for PerfSetULongCounterValue and PerfSetULongLongCounterValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
---
With past patches these two tests seem to pass reliably in the gitlab CI
environment:
https://gitlab.winehq.org/stefan/wine/-/merge_requests/8/pipelines
They passed in 5 out of 5 pipeline runs (and hopefully a 6th time in this
MR submission). Other tests failed though, so some of those pipeline runs
are marked as failures.
d3d9:d3d9ex still fails randomly on fvwm2/3 but passes on openbox.
d3d9:visual works on Mesa 21 and 23, but not Mesa 22. I'll look into these
tests in the next few weeks. I don't yet know why d3d8:visual is disabled.
I haven't looked at d3d10/11 at all yet.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3802
Based on a finding here: https://github.com/ValveSoftware/Proton/issues/6709#issuecomment-1626059391
On Windows, small (or 0) receive buffer works a bit differently when async IO is concerned. It is supposed to bypass some system buffering and receive the data directly to the user buffer if async receive is pending. So the apps may be using 0 buffer size as a small optimization to skip extra buffer copies in the system. On Unix, if the buffer is too small to receive the network packet the packet will just be dropped. As I interpret my tests though, Windows doesn't actually drop the packets with async socket even if there is no receive currently pending (looking like setting smaller buffer have no effect at all).
This behaves differently with synchronous IO, Windows can also drop packets which don't fit the smaller set buffer in this case.
I think that we can just never set receive buffers smaller than the default one on Unix sockets. The only effect of actually setting that which I can think of is that the system starts dropping packets more eagerly. Which is wrong for async socket I/O case. That might be not so wrong for sync socket I/O case, but implementing that specific to I/O type will add a lot of complication and will only lead that we will dropping packets more eagerly. While we are probably still won't be doing it exactly like on Windows as it depends on multiple factors in Unix and Windows network stack.
--
v2: server: Don't set SO_RCVBUF below Windows default value on Unix socket.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3705
This patch set is part of !3303
--
v4: winegstreamer: Create wg_muxer for media sink.
winegstreamer: Implement seeking query for wg_muxer sink pad.
winegstreamer: Introduce new wg_muxer struct.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3737
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v2: advapi32/tests: Create Tests for PerfSetULongCounterValue and PerfSetULongLongCounterValue
advapi32: Forward PerfSetULongCounterValue and PerfSetULongLongCounterValue to kernelbase
kernelbase: Add implementation of PerfSetULongCounterValue and PerfSetULongLongCounterValue
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
--
v2: mshtml: Get rid of the custom qi for CSS Styles.
mshtml: Forward objects' IUnknown methods to the DispatchEx.
mshtml: Get rid of `outer` in DispatchEx.
mshtml: Use query_interface in the dispex vtbl for PerformanceTiming.
mshtml: Use query_interface in the dispex vtbl for PerformanceNavigation.
mshtml: Use query_interface in the dispex vtbl for Performance.
mshtml: Use query_interface in the dispex vtbl for MediaQueryList.
mshtml: Use query_interface in the dispex vtbl for Console.
mshtml: Use query_interface in the dispex vtbl for Navigator.
mshtml: Use query_interface in the dispex vtbl for History.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3796
The validation code is meant both as a check that the frontend is behaving properly and as a sort of the documentation to establish what is allowed and what is not in the IR.
~~Currently an assertion is thrown if validation fails. I realize this is a rather strong proposal, but it's of course up for debate. In theory asserting here is the right thing, as it is expected that the frontend is generating correct IR code. However vkd3d is already used in production for many programs, and it could very well be that some of those are working properly even if the generated IR is somewhat out of specs; allowing the assertion might cause regressions as soon as enough checks are implemented in the validator. Please let me know your opinions.~~ **Solved in favor of a softer failure, and only when validation is enabled**
--
v7: vkd3d-shader/ir: Validate source parameters.
vkd3d-shader/ir: Validate destination parameters.
vkd3d-shader/ir: Validate register types.
vkd3d-shader/ir: Validate instruction handlers.
vkd3d-shader/ir: Introduce a boilerplate to validate the generated IR.
vkd3d-shader: Embed the parsing location in vkd3d_shader_instruction.
vkd3d-shader/dxil: Destroy the SM6 parser on parsing errors.
vkd3d-shader/tpf: Destroy the SM4 parser on parsing errors.
vkd3d-shader/d3dbc: Destroy the SM1 parser on parsing errors.
vkd3d-shader/d3dbc: Ignore DCL source parameters.
vkd3d-shader/ir: Simplify the control flow in shader_instruction_normalise_io_params().
vkd3d-shader/ir: Fully reinitialize an instruction when making it a NOP.
vkd3d-shader: Rename shader_instruction_init().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/317
If a Windows program writes a registry key of type REG_DWORD but puts more than 4 bytes of data in—I can't imagine why, but I am working with such a program—currently it is persisted as-is in the `WINEPATH` but `regedit` exports it as a `dword:%08x`, truncating the data.
This patch makes sure that only 4-byte DWORDs are exported as `dword:`; any other size falls through as a `hex(4):`.
(I chose to use the literal `4` here instead of `sizeof(DWORD)` because this value isn't directly coupled to the size of a `DWORD` as the compiler sees it; in the (extremely hypothetical?) world in which Wine is compiled with a `DWORD` of some other size, this value should still be 4, because `export_dword_data` will only correctly export something that can be represented in 8 hexadecimal characters.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3793
Rainbow 6 Siege and some other games require this. Type is printed in the FIXME to determine which type the application requires.
--
v4: gdi32: Add stub for D3DKMTQueryAdapterInfo.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3777
Based on a finding here: https://github.com/ValveSoftware/Proton/issues/6709#issuecomment-1626059391
On Windows, small (or 0) receive buffer works a bit differently when async IO is concerned. It is supposed to bypass some system buffering and receive the data directly to the user buffer if async receive is pending. So the apps may be using 0 buffer size as a small optimization to skip extra buffer copies in the system. On Unix, if the buffer is too small to receive the network packet the packet will just be dropped. As I interpret my tests though, Windows doesn't actually drop the packets with async socket even if there is no receive currently pending (looking like setting smaller buffer have no effect at all).
This behaves differently with synchronous IO, Windows can also drop packets which don't fit the smaller set buffer in this case.
I think that we can just never set receive buffers smaller than the default one on Unix sockets. The only effect of actually setting that which I can think of is that the system starts dropping packets more eagerly. Which is wrong for async socket I/O case. That might be not so wrong for sync socket I/O case, but implementing that specific to I/O type will add a lot of complication and will only lead that we will dropping packets more eagerly. While we are probably still won't be doing it exactly like on Windows as it depends on multiple factors in Unix and Windows network stack.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3705
This resolves 2 of 8 missing features needed by the Kirikiri visual novel engine.
--
v2: quartz: Delete some redundant members from struct quartz_vmr
quartz: Add test for VMR9SurfaceAllocatorNotify_ChangeD3DDevice
Add test for VMR9SurfaceAllocatorNotify_NotifyEvent
Recreate surfaces in VMR9SurfaceAllocatorNotify_ChangeD3DDevice
quartz: Fill in VMR9SurfaceAllocatorNotify_NotifyEvent stub
https://gitlab.winehq.org/wine/wine/-/merge_requests/3792
I have an application that creates its special registry key using
NtCreateKey(parent, "Something\0"), and then expects to be able to
open this key with NtOpenKey("Something\0") on start up. Currently
this fails because terminating '\0' in the key name doesn't survive
saving/loading the registry. parse_strW() helper already supports
loading such key names.
As the tests show after creating a kernel object with the name "Something\0"
it's possible to only open it as "Something\0", and an attempt opening it
as "Something" fails with STATUS_OBJECT_NAME_NOT_FOUND, and vice versa.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3790