March 2024 - Wine-gitlab - list.winehq.org

[PATCH 0/1] MR5289: dnsapi/tests: Skip tests if no CNAME records are returned.
by Hans Leidekker (＠hans) 12 Mar '24

12 Mar '24

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

2 1

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) 12 Mar '24

12 Mar '24

On Tue Mar 12 12:12:59 2024 +0000, Yuxuan Shui wrote: > @Alcaro `wg_parser_disconnect` frees all the streams `wg_parser_disconnect` and `wg_parser_destroy` frees the Unix-side streams. `reader->streams` is PE-side, and is not affected by wg_parser_disconnect/destroy. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64390

1 0

[PATCH v3 0/1] MR5286: kerberos: Allocate memory for the returned token if requested.
by Dmitry Timoshkov (＠dmitry) 12 Mar '24

12 Mar '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56400 -- v3: kerberos: Allocate memory for the output token if requested. https://gitlab.winehq.org/wine/wine/-/merge_requests/5286

3 2

Re: [PATCH v12 0/7] MR4449: winegstreamer: WMReader compressed output
by Yuxuan Shui (＠yshui) 12 Mar '24

12 Mar '24

On Mon Mar 11 22:52:33 2024 +0000, Alfred Agrell wrote: > It isn't. It's unchanged from init_stream. @Alcaro `wg_parser_disconnect` frees all the streams -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_64387

1 0

[PATCH 0/1] MR5272: ddraw: Reserve extra space in the reference device description buffer.
by Andrew Nguyen (＠arethusa) 12 Mar '24

12 Mar '24

During Direct3D device enumeration, Tomb Raider 3 modifies the buffer holding the Direct3D reference device description string. However, due to insufficient space in the buffer, the modification overruns the buffer and corrupts the IDirectDraw vtable, which leads to a crash on game startup. Reserving extra space in the description string buffer avoids the vtable corruption and allows the game to start. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56367 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5272

4 6

[PATCH v2 0/1] MR5286: kerberos: Allocate memory for the returned token if requested.
by Dmitry Timoshkov (＠dmitry) 12 Mar '24

12 Mar '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56400 -- v2: kerberos: Allocate memory for the output token if requested. https://gitlab.winehq.org/wine/wine/-/merge_requests/5286

3 4

[PATCH 0/1] MR5288: wineps.drv: Return default resolution if PPD doesn't provide the list of supported resolutions.
by Dmitry Timoshkov (＠dmitry) 12 Mar '24

12 Mar '24

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

3 2

[PATCH v4 0/3] MR692: vkd3d-shader/fx: Add "child-effect" compilation option.
by Nikolay Sivov (＠nsivov) 12 Mar '24

12 Mar '24

-- v4: vkd3d-shader/fx: Add support for writing shared object descriptions for fx_4_x. vkd3d-shader: Add an option to enable child effects compilation. vkd3d-shader/fx: Add initial support for writing uninitialized vertex/pixel shader objects. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/692

3 5

Re: [PATCH v5 0/3] MR4915: d3d9: Implement Direct3DCreate9On12().
by Jan Sikorski (＠jsikorski) 12 Mar '24

12 Mar '24

Sorry for the long silence. A couple of nits above, but generally that looks fine to me. My understanding is that we could in principle have a client that calls Microsoft's d3d9on12.dll instead of returning our d3d9, is that right? The games just go through `Direct3DCreate9On12` but then only use the D3D9 interface? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4915#note_64358

1 0

Re: [PATCH v5 0/3] MR4915: d3d9: Implement Direct3DCreate9On12().
by Jan Sikorski (＠jsikorski) 12 Mar '24

12 Mar '24

Jan Sikorski (@jsikorski) commented about dlls/d3d9/d3d9on12.c: > + d3d9on12_ReturnUnderlyingResource, > +}; > + > +BOOL d3d9on12_init( struct d3d9on12 **d3d9on12, D3D9ON12_ARGS *override_list, UINT override_entries ) > +{ > + struct d3d9on12 *object; > + > + if (!override_list || !override_list->Enable9On12 || !override_entries) > + { > + *d3d9on12 = NULL; > + return TRUE; > + } > + > + if (!(object = calloc( 1, sizeof(*object) ))) > + return FALSE; > + if (!(object->override_list = calloc( 1, sizeof(D3D9ON12_ARGS) ))) That's a bit odd: if we only care about the first entry, why not just store it in a static member? Or if we don't care about it, don't store it at all? To me, use of `calloc` here indicates an intention that I'm missing. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4915#note_64355

1 0