- Wine-devel - list.winehq.org

[PATCH vkd3d 2/2] include: Add ID3D12Device3 declaration in vkd3d_d3d12.idl.
by Biswapriyo Nath 16 Jun '22

16 Jun '22

2 1

[PATCH vkd3d 1/2] include: Add more D3D12_HEAP_FLAGS in vkd3d_d3d12.idl.
by Biswapriyo Nath 16 Jun '22

16 Jun '22

2 1

[PATCH 0/5] MR237: winegstreamer: Implement Resampler and ColorConvert MF transforms.
by Rémi Bernon 16 Jun '22

16 Jun '22

I don't think this will cause any conflicts with the other MR, as long as the `wg_sample` API doesn't change. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/237

4 10

[PATCH 0/1] MR259: d3d11: Remove null dxgi object checks.
by Nikolay Sivov (＠nsivov) 16 Jun '22

16 Jun '22

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/259

2 1

Re: [PATCH v5 0/7] MR212: d3d11: Create dxgi resource objects for textures and buffers.
by Nikolay Sivov (＠nsivov) 16 Jun '22

16 Jun '22

Another thing that I noticed, that is potentially relevant to how relationship between d3d11 and dxgi objects is tracked, is IDXGIResource1::CreateSubresourceSurface. I didn't do any testing with it, but it implies you can create multiple dxgi objects for the same d3d11/wined3d resource, at least as many as subresource count, but potentially any number of them. Right now afaict lifetime is tracked in d3d11 object, and dxgi one do not take a reference to them. So i'm not sure yet, how this is supposed to coexist. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/212#note_2188

1 0

[PATCH 0/1] MR252: shell32/tests: Add tests for Program Manager name sanitization.
by Alex Henrie (＠alexhenrie) 16 Jun '22

16 Jun '22

Split from https://gitlab.winehq.org/wine/wine/-/merge_requests/23 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/252

3 2

[PATCH 0/1] MR172: dlls/win32u: fix gcc12's warnings (UB)
by eric pouech (＠epo) 16 Jun '22

16 Jun '22

GCC12.* emits tons of warnings when compiling win32'u sysparam bits These warnings stem from: - a union of different structures - allocating one instance of these structure and casting its address to a pointer to the union. This is UB as the whole union should be allocated in order to be a valid object. I tried to keep the original goals: - don't overallocate individual structures - have an OO design (and avoid casting back & forth arguments in methods) and implemented this fix by transforming (as argument to most of the methods) - a pointer to an union of structs into - an union (passed by value) of pointers to structs Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/172

3 4

[PATCH v4 0/6] MR73: Improvement in PDB's types record handling
by eric pouech (＠epo) 16 Jun '22

16 Jun '22

This serie tackles several issues encountered while loading PDB files through dbghelp. It happens that PDB allows to have several type records for user defined types (struct / enums) with the same name. This seems to be generated by a) compiler (when modifying a structure definition between several compilation phases), b) the incremental linker (likely an optimisation of previous case, but not 100% certain when it's triggered). Wine's dbghelp ended up not picking the right record, hence generating errneous outputs. This series: - cleans up some PDB related code - update winedump to display the PDB hash table internals - fixes dbghelp to preserve in Wine's dbghelp hash table the partial order between type records of same name. v2: - rebased - removed a bunch of stray comments -- v4: dlls/dbghelp{pdb}: use remap table from PDB hash stream dlls/dbghelp{pdb}: ensure dbghelp's list order in hash table matches PDB's dlls/dbghelp{pdb}: clearly separate the type loading into two passes include/wine/mscvpdb.h: redefine property with bitfields dlls/dbghelp{pdb}: rely on first/last index from type header tools/winedump{pdb}: explore a bit more TPI hash elements https://gitlab.winehq.org/wine/wine/-/merge_requests/73

2 8

[PATCH 0/3] MR224: Fix GCC12 warnings
by eric pouech (＠epo) 16 Jun '22

16 Jun '22

Fixes a couple of warnings emitted by GCC12 compiler -- https://gitlab.winehq.org/wine/wine/-/merge_requests/224

2 4

Wiki guidance on taking function prototypes from ReactOS
by Alex Henrie 16 Jun '22

16 Jun '22

Yesterday I came across a bug report [1] with an attached patch to stub out the function RtlGetFullPathName_UEx, which is not documented by Microsoft, based on its prototype in ReactOS. Alexandre left the comment: [2] "You should not look at ReactOS code at all, a lot of it is reverse-engineered using methods that are not appropriate for Wine. It's not a usable source of information for us." The patch author, Ben, replied: [3] "I just want the WIKI to be MUCH more definitive/precise on what IS and IS NOT allowed." I took a look and as it currently stands, the wiki clearly encourages collaboration with ReactOS in at least one place: [4] "If you're still resisting the switch to unix for some reason though, you may have some luck investigating ReactOS (they cooperate with us on API issues too)." And it clearly discourages collaboration with ReactOS in at least one place: [5] "it appears that all such documentation is derived from ReactOS, which is not considered a legally safe source for use in Wine." Mention of ReactOS is conspicuously absent from the page that outlines Wine's "clean room" guidelines. [6] Since Alexandre says that Wine developers shouldn't look at ReactOS code at all, I think we should remove from the wiki all references that might be construed to encourage it and add some more that discourage it. Does anyone have any further thoughts before I start editing? -Alex [1] https://bugs.winehq.org/show_bug.cgi?id=50464 [2] https://bugs.winehq.org/show_bug.cgi?id=50464#c6 [3] https://bugs.winehq.org/show_bug.cgi?id=50464#c7 [4] https://wiki.winehq.org/Cygwin_and_More [5] https://wiki.winehq.org/AFD [6] https://wiki.winehq.org/Clean_Room_Guidelines

2 1