November 2022 - Wine-GitLab

[PATCH 0/1] MR1380: dpnet: Use standard C functions for memory allocation in address.c.
by Alex Henrie (＠alexhenrie) Nov. 16, 2022

Nov. 16, 2022

The big win here is getting rid of the reimplementation of strdup. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1380

3 2

[PATCH 0/1] MR1376: ole32: Fix memory leak on error path in CompositeMonikerImpl_CommonPrefixWith (Coverity).
by Alex Henrie (＠alexhenrie) Nov. 15, 2022

Nov. 15, 2022

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

3 5

[PATCH 0/1] MR1379: comdlg32: Use standard C functions for memory allocation in printdlg.c.
by Alex Henrie (＠alexhenrie) Nov. 15, 2022

Nov. 15, 2022

The big win here is getting rid of the reimplementation of wcsdup. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1379

3 2

[PATCH v2 0/1] MR1378: sspicli: Use standard C functions for memory allocation.
by Alex Henrie (＠alexhenrie) Nov. 15, 2022

Nov. 15, 2022

The big win here is getting rid of the reimplementation of wcsdup. -- v2: sspicli: Use standard C functions for memory allocation. https://gitlab.winehq.org/wine/wine/-/merge_requests/1378

2 1

[PATCH 0/1] MR1383: inetcomm: Use standard C functions for memory allocation in mimeole.c.
by Alex Henrie (＠alexhenrie) Nov. 15, 2022

Nov. 15, 2022

The big win here is getting rid of the reimplementation of strdup. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1383

2 1

[PATCH 0/1] MR1377: dsound: Use standard C functions for memory allocation in propset.c.
by Alex Henrie (＠alexhenrie) Nov. 15, 2022

Nov. 15, 2022

The big win here is getting rid of the reimplementation of wcsdup. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1377

3 2

[PATCH 0/1] MR1375: ole32: Correct warning message in composite_get_leftmost.
by Alex Henrie (＠alexhenrie) Nov. 15, 2022

Nov. 15, 2022

Looks like a copy-paste error. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1375

3 2

[PATCH 0/1] MR1378: sspicli: Use standard C functions for memory allocation.
by Alex Henrie (＠alexhenrie) Nov. 15, 2022

Nov. 15, 2022

The big win here is getting rid of the reimplementation of wcsdup. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1378

2 1

[PATCH v11 0/10] MR1148: ntdll: Mark created files beginning with a dot as not hidden.
by Torge Matthies (＠tmatthies) Nov. 15, 2022

Nov. 15, 2022

Also unifies hidden file handling. Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826). -- v11: ntdll: Try to avoid requesting the file name for a handle. ntdll: Ensure that attributes are kept the same when renaming or hard-linking a file. ntdll: Set xattr in NtCreateFile if inferred and requested attributes don't match. ntdll: Only infer hidden attribute from file name if xattr is not present. ntdll: Handle hidden file names in fd_get_file_info. ntdll: Pass file path into fd_get_file_info if available. ntdll: Do not compute file attributes for info classes that don't need them. ntdll: Handle hidden file names inside get_file_info instead of after it. ntdll: Do not open-code hidden file handling in get_dir_data_entry. ntdll/tests: Add test for file attributes of files with names beginning with a dot. https://gitlab.winehq.org/wine/wine/-/merge_requests/1148

2 10

Re: [PATCH v3 0/4] MR1311: wmvcore: Implement DedicatedDeliveryThread async reader output setting.
by Zebediah Figura (＠zfigura) Nov. 15, 2022

Nov. 15, 2022

On Tue Nov 15 21:40:55 2022 +0000, Rémi Bernon wrote: > Because this is a blocking call, which can call application callbacks, > or otherwise also blocking until there's a sample ready. > We want to be able to deliver samples from the callback thread, on other > streams, without being blocked and without blocking the reader. There's > no point in making all this asynchronous otherwise. GetNextSample() already calls callbacks with the lock held. I.e. this is basically doing the same thing as described above. I also don't see how delivering samples can block this, or the reverse, since we drop the CS in order to deliver samples. What deadlock results from not dropping the CS here? I would guess that AllocateForOutput() is blocking in IMemAllocator::GetBuffer(), but if that's the case, according to my reading of 2/4, we should either be inside of IWMReaderCallback::OnSample() or still holding the CS and about to call it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15909

1 0