October 2022 - Wine-GitLab - list.winehq.org

Re: [PATCH v6 0/9] MR1148: ntdll: Mark created files beginning with a dot as not hidden.
by Torge Matthies (＠tmatthies) Oct. 26, 2022

Oct. 26, 2022

forgot to rebase before push -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1148#note_12167

1 0

[PATCH v5 0/9] MR1148: ntdll: Mark created files beginning with a dot as not hidden.
by Torge Matthies (＠tmatthies) Oct. 26, 2022

Oct. 26, 2022

Also unifies hidden file handling. Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826). -- v5: ntdll: Ensure that attributes are kept the same when renaming 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. https://gitlab.winehq.org/wine/wine/-/merge_requests/1148

2 10

[PATCH v3 0/4] MR1122: comctl32: property sheet improvements
by Piotr Caban (＠piotr) Oct. 26, 2022

Oct. 26, 2022

-- v3: comctl32: Add support for adding extra data in CreatePropertySheetPage. comctl32: Fix PROPSHEETPAGE[AW] structure content in messages and callbacks. comctl32: Don't use PROPSHEETPAGE structure to store internal HPROPSHEETPAGE data. comctl32: Create page if PROPSHEETPAGE was passed as HPROPSHEETPAGE to PropertySheetAW or PSM_INSERTPAGE. https://gitlab.winehq.org/wine/wine/-/merge_requests/1122

4 6

[PATCH v5 0/5] MR741: ntdll: Implement NtFlushProcessWriteBuffers.
by Torge Matthies (＠tmatthies) Oct. 26, 2022

Oct. 26, 2022

Based on [a patch](https://www.winehq.org/mailman3/hyperkitty/list/wine-devel(a)winehq.… by Jinoh Kang (@iamahuman) from February 2022. I removed the need for the event object and implemented fast paths for Linux. On macOS 10.14+ `thread_get_register_pointer_values` is used on every thread of the process. On Linux 4.14+ `membarrier(MEMBARRIER_CMD_GLOBAL_EXPEDITED, ...)` is used. On x86 Linux <= 4.13 `madvise(..., MADV_DONTNEED)` is used, which sends IPIs to all cores causing them to do a memory barrier. On non-x86 Linux <= 4.2 and on other platforms the fallback path using APCs is used. -- v5: ntdll: Add thread_get_register_pointer_values-based fast path for NtFlushProcessWriteBuffers. https://gitlab.winehq.org/wine/wine/-/merge_requests/741

4 11

[PATCH v5 0/3] MR1070: Add more tests for \Device\NamedPipe, \Device\NamedPipe\, and exotic pipe names
by Jinoh Kang (＠iamahuman) Oct. 25, 2022

Oct. 25, 2022

-- v5: ntdll/tests: Add more tests for \Device\NamedPipe and \Device\NamedPipe\. ntdll/tests: Add tests for pipe names. https://gitlab.winehq.org/wine/wine/-/merge_requests/1070

4 6

[PATCH v4 0/6] MR1148: ntdll: Mark created files beginning with a dot as not hidden.
by Torge Matthies (＠tmatthies) Oct. 25, 2022

Oct. 25, 2022

Also unifies hidden file handling. Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826). -- v4: ntdll: Ensure that attributes are kept the same when renaming 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: Consistently handle dot files in file functions. 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

4 9

Re: [PATCH v4 0/3] MR1003: gdiplus: Use atomic write for releasing GpImage lock.
by Zebediah Figura (＠zfigura) Oct. 25, 2022

Oct. 25, 2022

On Tue Oct 25 21:12:39 2022 +0000, Esme Povirk wrote: > There are two different kinds of "locking" going on here. There's > GdipLockBitmapBits, which isn't a locking mechanism at all but a way of > accessing bitmap data, and the mutex we have protecting Bitmap objects. > Also, error 7 is a gdiplus Status enum value named Win32Error, not a > win32 error code, so this isn't ERROR_ARENA_TRASHED. > This test case is entirely single-threaded, so it's not a race > condition. The mutex-lock isn't really involved. It seems like gdiplus > does not account for GdipImageRotateFlip being called while a bitmap is > bits-locked. I would guess that RotateFlip changes the location of the > image data, invalidating the state that UnlockBits needs to function > correctly. What "should" happen in this situation is probably that > GdipImageRotateFlip fails with WrongState, but it seems Windows doesn't > do that. > The patches here bring us closer to the (broken) Windows behavior, > although I'm really not sure how Wine will end up handling this > situation in practice. Ah, okay, I made a lot of assumptions, and didn't actually examine the test case. Sorry about that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1003#note_12127

1 0

Re: [PATCH v4 0/3] MR1003: gdiplus: Use atomic write for releasing GpImage lock.
by Esme Povirk (＠madewokherd) Oct. 25, 2022

Oct. 25, 2022

On Tue Oct 25 21:03:54 2022 +0000, Zebediah Figura wrote: > That behaviour sounds an awful lot like gdiplus isn't thread-safe after > all. E.g. error 7 is ERROR_ARENA_TRASHED. Should this code really have a > lock at all? There are two different kinds of "locking" going on here. There's GdipLockBitmapBits, which isn't a locking mechanism at all but a way of accessing bitmap data, and the mutex we have protecting Bitmap objects. Also, error 7 is a gdiplus Status enum value named Win32Error, not a win32 error code, so this isn't ERROR_ARENA_TRASHED. This test case is entirely single-threaded, so it's not a race condition. The mutex-lock isn't really involved. It seems like gdiplus does not account for GdipImageRotateFlip being called while a bitmap is bits-locked. I would guess that RotateFlip changes the location of the image data, invalidating the state that UnlockBits needs to function correctly. What "should" happen in this situation is probably that GdipImageRotateFlip fails with WrongState, but it seems Windows doesn't do that. The patches here bring us closer to the (broken) Windows behavior, although I'm really not sure how Wine will end up handling this situation in practice. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1003#note_12125

1 0

[PATCH v6 0/3] MR1164: Draft: gdiplus: add initial CompoundLine support to fix application crash
by Bartosz Kosiorek (＠gang65) Oct. 25, 2022

Oct. 25, 2022

Wine-bug: https://bugs.winehq.org/show_bug.cgi?id=52196 -- v6: gdiplus: add GdipGetPenCompoundArray implementation https://gitlab.winehq.org/wine/wine/-/merge_requests/1164

4 5

Re: [PATCH v4 0/3] MR1003: gdiplus: Use atomic write for releasing GpImage lock.
by Zebediah Figura (＠zfigura) Oct. 25, 2022

Oct. 25, 2022

On Sun Oct 23 20:06:50 2022 +0000, Esme Povirk wrote: > I think that behavior is strange enough that we shouldn't worry about > it, at least not until we see a real app doing this. Thank you for checking. That behaviour sounds an awful lot like gdiplus isn't thread-safe after all. E.g. error 7 is ERROR_ARENA_TRASHED. Should this code really have a lock at all? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1003#note_12119

1 0