September 2023 - Wine-GitLab

[PATCH 0/1] MR3847: winmm: Handle memory allocation failure in WINMM_OpenDevice (cppcheck).
by Alex Henrie (＠alexhenrie) Sept. 15, 2023

Sept. 15, 2023

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

3 2

[PATCH v2 0/4] MR3848: wine{alsa,coreaudio,oss,pulse}: Ensure unixlib function tables and enum stay in sync.
by Brendan Shanks (＠bshanks) Sept. 15, 2023

Sept. 15, 2023

-- v2: winepulse: Ensure unixlib function tables and enum stay in sync. wineoss: Ensure unixlib function tables and enum stay in sync. winecoreaudio: Ensure unixlib function tables and enum stay in sync. winealsa: Ensure unixlib function tables and enum stay in sync. https://gitlab.winehq.org/wine/wine/-/merge_requests/3848

3 5

[PATCH 0/1] MR3850: capi2032: Ensure unixlib function tables and enum stay in sync.
by Brendan Shanks (＠bshanks) Sept. 14, 2023

Sept. 14, 2023

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

2 1

[PATCH v2 0/1] MR3849: netapi32: Ensure unixlib function tables and enum stay in sync.
by Brendan Shanks (＠bshanks) Sept. 14, 2023

Sept. 14, 2023

-- v2: netapi32: Ensure unixlib function tables and enum stay in sync. https://gitlab.winehq.org/wine/wine/-/merge_requests/3849

2 1

[PATCH 0/1] MR3849: netapi32: Ensure unixlib function tables and enum stay in sync.
by Brendan Shanks (＠bshanks) Sept. 14, 2023

Sept. 14, 2023

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

2 1

[PATCH 0/4] MR3848: wine{alsa,coreaudio,oss,pulse}: Ensure unixlib function tables and enum stay in sync.
by Brendan Shanks (＠bshanks) Sept. 14, 2023

Sept. 14, 2023

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

2 4

[PATCH 0/1] MR3844: odbccp32: Handle memory allocation failure in SQLGetInstalledDriversW (cppcheck).
by Alex Henrie (＠alexhenrie) Sept. 14, 2023

Sept. 14, 2023

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

3 2

[PATCH 0/1] MR3845: ntdll: Fix leave_handler for FreeBSD and NetBSD
by Gerald Pfeifer (＠gerald) Sept. 14, 2023

Sept. 14, 2023

With recent changes leave_handler writes to some of its parameter's fields (via DS_sig and ES_sig) on FreeBSD and NetBSD - which fails since it is declared const. Accordingly strip const-ness. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3845

2 1

Re: [PATCH v5 0/5] MR3792: Fill in some VMR9 stubs
by Alfred Agrell (＠Alcaro) Sept. 14, 2023

Sept. 14, 2023

...nope, my VM no longer works. I'm just getting nonsensical errors (why would IVMRSurfaceAllocatorNotify9_SetD3DDevice return E_NOINTERFACE), even from programs that worked last time I tried. I'd suspect some broken update somewhere, GPU stuff has always been finicky in VMs. I'd be happy to fix this test if I could, but without access to a functional Windows installation, there's not much I can do :/ Though I have done some manual testing with some real-world programs, so I'm confident that it's better than the previous stub, at least. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3792#note_45450

1 0

Re: [PATCH v4 0/2] MR340: vkd3d-shader/hlsl: Document some possibly obscure HLSL opcodes.
by Giovanni Mascellani (＠giomasce) Sept. 14, 2023

Sept. 14, 2023

> HLSL_IR_STORE and HLSL_IR_RESOURCE_STORE exist though. I don't think you can use those as HLSL_IR_EXPR sources (right?), but that might not necessarily be obvious. As this MR proves, we're not in an overabundance of documentation about the HLSL IR, that's sure. In my interpretation, the fact that `HLSL_IR_STORE` and `HLSL_IR_RESOURCE_STORE` don't evaluate to a value is of little relevance. Even if they did, they are executed if the control flow reach them, not if their result is used. I realize that my sentence "Nodes purely forward a value and have no side effects" has probably a poor choice of words: of course nodes, which we use essentially as a synonym for "instructions", of course do have side effects (in general, at least). What I wanted to say is probably more like "References purely forward a value [etc]": the act of recalling the value produced by an earlier node/instruction has no side effect, therefore the question if `MOVC` evaluates the operand which is not selected is empty: the operand doesn't bear any side effect, be it selected or not; and the referenced node/instruction is evaluated (possibly with side effects) independently of its value being selected by `MOVC` or not, simply by virtue of being in the control flow; it would have been evaluated even if `MOVC` didn't have it as an operand at all. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/340#note_45445

1 0