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

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

25 Oct '22

-- 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) 25 Oct '22

25 Oct '22

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) 25 Oct '22

25 Oct '22

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) 25 Oct '22

25 Oct '22

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) 25 Oct '22

25 Oct '22

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) 25 Oct '22

25 Oct '22

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

[PATCH v5 0/3] MR1164: Draft: gdiplus: add initial CompoundLine support to fix application crash
by Bartosz Kosiorek (＠gang65) 25 Oct '22

25 Oct '22

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

3 4

[PATCH v3 0/3] MR1164: Draft: gdiplus: add initial CompoundLine support to fix application crash
by Bartosz Kosiorek (＠gang65) 25 Oct '22

25 Oct '22

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

3 4

[PATCH v5 0/115] MR955: Draft: Release 7.0.1.
by Michael Stefaniuc (＠mstefani) 25 Oct '22

25 Oct '22

This is wine-7.0.1-rc1, so not ready yet to merge. -- v5: Release 7.0.1. gitlab: Import the gitlab CI from the master branch (devel tree) winetest: Don't require an email if we have a URL. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/955

1 0

[PATCH v2 0/1] MR1153: winex11.drv: Correctly handle clipping for fullscreen windows.
by Gabriel Ivăncescu 25 Oct '22

25 Oct '22

When we are clipping (due to fullscreen), certain operations are bugged (such as creating another window on top, grabbing the window during a size-move operation, changing mouse capture, etc) so we must temporarily unclip first. Seems unclipping it temporarily during such operation is enough to fix this. This probably wasn't very obvious in practice because most times "fullscreen" means a single non-resizeable window with no menus and so on (e.g. fullscreen games), but that's not always the case. -- v2: winex11.drv: Correctly handle clipping for fullscreen windows. https://gitlab.winehq.org/wine/wine/-/merge_requests/1153

2 2