December 2023 - wine-gitlab

[PATCH v2 0/6] MR4573: More CreateProcess work.
by eric pouech (＠epo) 05 Dec '23

05 Dec '23

This series mainly: - tests and implement fixes for GetStartupInfoW: + it should transform PEB's RTL_USER_PROCESS_PARAMETERS on the fly (instead of caching the results as GetStartupInfoA) + it doesn't set all the fields of returned in STARTUPINFOW (unlike GetStartupInfoA) - no longer allow console and console handles for non CUI apps: + forbid inheritance of console handles for non CUI apps + don't create a unix console for initial (non CUI) app -- v2: ntdll,start: Don't create Unix console for GUI apps. ntdll: Don't inherit std console handles for non CUI child process. kernelbase: GetStartupInfoW: set std handle only when USESTDHANDLES is set. kernelbase: No longer cache GetStartupInfoW() results. kernel32/tests: Add tests for GetStartupInfo(A|W). kernel32/tests: Identify untouched fields returned from GetStartupInfo. https://gitlab.winehq.org/wine/wine/-/merge_requests/4573

3 9

[PATCH 0/1] MR4599: msxml3: Handle default namespace in get_nodeName.
by Daniel Lehman (＠dlehman25) 05 Dec '23

05 Dec '23

3rd of 5 request to remove the todos i added combined result of remaining requests: https://gitlab.winehq.org/dlehman25/wine/-/tree/msxml-nullpfx-combined -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4599

3 2

Re: [PATCH v2 0/7] MR4602: winevulkan: Fix host / driver handle unwrapping.
by Rémi Bernon (＠rbernon) 05 Dec '23

05 Dec '23

v2: Remove unnecessary direction named parameter change, I initially replaced the unwrap parameter earlier and it was more readable with named parameters but later changed my mind. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4602#note_55035

1 0

[PATCH 0/7] MR4602: winevulkan: Fix host / driver handle unwrapping.
by Rémi Bernon (＠rbernon) 05 Dec '23

05 Dec '23

Split from https://gitlab.winehq.org/wine/wine/-/merge_requests/4572 When there's driver wrappers the handles are always unwrapped to driver handles, including for functions which don't have a driver entry point. This fixes that and unwrap to host / driver depending on the functions. Extension chains are still always unwrapped to host handles for now. I have pushed some sample change to wrap swapchain handles in https://gitlab.winehq.org/rbernon/wine/-/commit/3181c3adbb3abd5967e947dfd42… and https://gitlab.winehq.org/rbernon/wine/-/commit/00220d8b80d0d39ce003232f47a…, without the last change in this MR they would look like https://gitlab.winehq.org/rbernon/wine/-/commit/470b67c514028983b23d3118377… and https://gitlab.winehq.org/rbernon/wine/-/commit/122980f2b04a60661533599b513… respectively. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4602

2 7

[PATCH 0/4] MR4591: amstream, winegstreamer: Quality control improvements.
by Anton Baskanov (＠baskanov) 05 Dec '23

05 Dec '23

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

5 7

[PATCH v5 0/11] MR498: Draft: vkd3d-shader/dxil: Implement the DXIL ALLOCA and STORE instructions.
by Conor McCarthy (＠cmccarthy) 05 Dec '23

05 Dec '23

Goes atop !477. The last two commits belong to this MR. -- v5: tests/shader-runner: Add a non-const-indexing test for asfloat() result storage. vkd3d-shader/spirv: Bitcast if necessary in the spirv_compiler_emit_mov() general implementation. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/498

2 11

[PATCH v4 0/9] MR498: Draft: vkd3d-shader/dxil: Implement the DXIL ALLOCA and STORE instructions.
by Conor McCarthy (＠cmccarthy) 05 Dec '23

05 Dec '23

Goes atop !477. The last two commits belong to this MR. -- v4: vkd3d-shader/dxil: Implement the DXIL STORE instruction. vkd3d-shader/dxil: Implement the DXIL ALLOCA instruction. tests/shader-runner: Test an uninitialised indexable temp. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/498

2 9

Re: [PATCH v9 0/1] MR3970: quartz/tests: Improve VMR9 ChangeD3DDevice test
by Zebediah Figura (＠zfigura) 05 Dec '23

05 Dec '23

On Tue Dec 5 01:23:40 2023 +0000, Alfred Agrell wrote: > I don't know what Microsoft's intention is or what's officially > supported, but a quick WINEDEBUG=trace+quartz tells me that Kirikiri > does, in fact, call ChangeD3DDevice while the graph is connected but > stopped. It's the last thing it does before IMediaControl::Run(). > (Kirikiri doesn't pause the graph, it just goes directly to Run.) > Kirikiri's source code also shows that the function is called if > IDirect3DDevice9::Present returns D3DERR_DEVICELOST; Present() is only > plausible while paused or running, though I don't know if that code path > was ever tested. > (Also rebased this thing. No other changes.) Fair enough, I can only assume they avoid the race somehow else then, e.g. by always happening to wait the few ms necessary to ensure the asynchronous reconnect completes. It certainly wouldn't surprise me. In any case I think the best thing we can do for the tests is to not test that case. We want the tests to pass consistently, and experience has taught me that the only way to achieve that is to never rely on Sleep(). The stopped case should be interesting enough by itself anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3970#note_55004

1 0

Re: [PATCH v3 0/1] MR4578: include: Add Windows.Storage.Streams.InMemoryRandomAccessStream runtimeclass definition.
by Fabian Maurer (＠DarkShadow44) 05 Dec '23

05 Dec '23

On Fri Dec 1 21:45:23 2023 +0000, Vijay Kiran Kamuju wrote: > According the idl its activatable, but I was not sure how to add the > activatable as its in hex > [activatable(0x06020000)] Probably just `activatable(Windows.Foundation.UniversalApiContract, 1.0)`. But I'm pretty sure you need that activatable if you want it to be usable later. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4578#note_54999

1 0

Re: [PATCH v8 0/1] MR3970: quartz/tests: Improve VMR9 ChangeD3DDevice test
by Alfred Agrell (＠Alcaro) 05 Dec '23

05 Dec '23

On Tue Dec 5 01:21:52 2023 +0000, Zebediah Figura wrote: > I did some more digging on this one, and here is what my testing suggests: > * native ChangeD3DDevice() *just* reconnects the filter, i.e. it doesn't > directly call any of the same methods. > * This reconnection is done on a separate thread, for some reason. IPin > methods and IVMRSurfaceAllocator::TerminateDevice() are called from that thread. > * The filter graph documentation claims that IFilterGraph::Reconnect() > and IFilterGraph2::ReconnectEx() execute on a separate thread, but > according to my tests this is not true. > * ChangeD3DDevice() can be called while the filter is running, in which > case it will stop the graph, reconnnect, and then run. This is all done > on the same thread. Note that ReconnectEx() *cannot* be called while the > filter is running. > * ChangeD3DDevice() can be called while the filter is not connected. > * InitializeDevice() is not called immediately on connection. Rather, it > seems to be deferred until IMemAllocator::SetProperties(). > VFW_E_NOT_COMMITTED happens because reconnecting evidently decommits the > allocator, and we manage to race exactly such that the pins have been > disconnected but not yet reconnected when trying to send a frame. > As far as I can tell there is no actual way to synchronize this thread. > I suspect that in practice ChangeD3DDevice() is not expected to be > called while connected and stopped. I don't know if it's meant to be > called while disconnected or while running, or both. Either will avoid > this race, although ChangeD3DDevice() while running will definitely run > into other races surrounding state change (e.g. what happens if you > ChangeD3DDevice() and then decide to stop the graph?) > I think the only case we can really reliably test is the stopped case. I don't know what Microsoft's intention is or what's officially supported, but a quick WINEDEBUG=trace+quartz tells me that Kirikiri does, in fact, call ChangeD3DDevice while the graph is connected but stopped. It's the last thing it does before IMediaControl::Run(). (Kirikiri doesn't pause the graph, it just goes directly to Run.) Kirikiri's source code also shows that the function is called if IDirect3DDevice9::Present returns D3DERR_DEVICELOST, which only happens while paused or running, though I don't know if that code path was ever tested. (Also rebased this thing. No other changes.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3970#note_54997

1 0

2025

2024

2023

2022

wine-gitlab December 2023