- Wine-GitLab - list.winehq.org

[PATCH v3 0/8] MR871: ntdll: Fill the IOSB only inside the if (alerted) block in multiple functions.
by Zebediah Figura (＠zfigura) Sept. 27, 2022

Sept. 27, 2022

-- v3: ntdll: Combine the "if (alerted)" blocks in sock_transmit(). ntdll: Fill the IOSB in sock_transmit() only inside the "if (alerted)" block. ntdll: Combine the "if (alerted)" blocks in sock_send(). ntdll: Fill the IOSB in sock_send() only inside the "if (alerted)" block. ntdll: Combine the "if (alerted)" blocks in sock_recv(). ntdll: Fill the IOSB in sock_recv() only inside the "if (alerted)" block. ntdll: The async handle passed to set_async_direct_result() cannot be NULL. ws2_32/tests: Add more tests for iosb contents while a recv is pending. https://gitlab.winehq.org/wine/wine/-/merge_requests/871

2 8

Re: [PATCH v2 0/1] MR11: vkd3d: Add a macro to mark unreachable code. - approved
by Zebediah Figura (＠zfigura) Sept. 27, 2022

Sept. 27, 2022

This merge request was approved by Zebediah Figura. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/11

1 0

Re: [PATCH v3 0/2] MR897: oleaut32: dereference VT_RECORD|VT_BYREF in place.
by Kevin Puetz (＠puetzk) Sept. 26, 2022

Sept. 26, 2022

@julliard, did you intend merge this despite the failing conformance tests (see thread above from Marvin)? I still think the fix is "correct", i.e. this *should* workand windows is just buggy too - but the conformance tests certainly showed my fix is not really justified (since this doesn't work on windows either) and our use that led me to make this change was just getting lucky in a weird way and needs to be changed. I hadn't just closed it because I was going to eventually salvage the tests into a fix for the memleak they revealed. But I wasn't expecting you'd to accept it after Marvin shot me down... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/897#note_9337

1 0

Re: [PATCH v2 0/8] MR924: ntdll: Add support for DOS file attributes
by Joel Holdsworth (＠jhol) Sept. 26, 2022

Sept. 26, 2022

On Mon Sep 26 19:51:22 2022 +0000, **** wrote: > Zebediah Figura replied on the mailing list: > ``` > Hello Joel, > I haven't looked at these patches in detail, largely because there's > still outstanding test failures, but I do have one high-level comment, > which is that I'd recommend starting with the basic implementation (i.e. > just the first four patches), and leave the rest for separate merge > requests. Since merge requests can only be applied as a whole I think it > makes sense to narrow this down to a more minimal set, and try to get > one thing done at a time. > ``` Hi Zebediah - thanks for taking a look. I don't mind narrowinging the commit series down. This patch set is mainly trying to get these attribute flags working: * `FILE_ATTRIBUTE_HIDDEN` * `FILE_ATTRIBUTE_SYSTEM` * `FILE_ATTRIBUTE_READONLY` (to a lesser extent - because this is already quite well represented by UNIX access permissions) The trouble is that while we want to seamlessly integrate with the underlying filesystems, the availability of different methods varies between operating systems and filesystems. This version of the patch set offers three strategies, and I found a two more possible methods that should be added today ([1](https://man7.org/linux/man-pages/man2/ioctl_iflags.2.html) [2](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/… ). The code attempts to store the flags by all available methods at once for a given file, and ORs the flags together from any available source, in the hopes we can deliver the most complete coverage to the user. However, because there is no fallback method, it is currenly not possible to guaruantee that the attributes will always be stored and retrieved correctly in all scenaries. If we only include the first four patches, the patch set will only support storage in Samba-formatted Extended File Attributes. If we unmark the associated test cases as `todo_wine`, the test will break on certain operating systems or certain mount flag choices. There is no support for Extended Attributes on FreeBSD or NetBSD, for example, and the MacOS Extended Atrribute APIs differ from the Linux ones. One approach is to fall back to using a `.dosattributes` directory when no other storage method is available, and store the attributes in files inside there. However, I didn't want to implement this functionality before having a conversation with the Wine project developers. I have been in conversation with @ehoover in the last couple of days concerning his work on Junction Points, which is a related topic to DOS attributes, and also causes issues for Msys2 in its own right. His strategy is to store the required metadata in a [`.REPARSE_POINT` hidden directory](https://github.com/wine-staging/wine-staging/blob/master/patches…. There is also the storage of [NT extended-attribute (EA)](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/n…) values to consider, when we move toward a non-stub implementation of this feature. Perhaps it would be preferable to produce a design that can be encompass all these issues. Do we need to resolve this design question here and now? Or can we just proceed with Linux-only Extended Attributes in the short term? I think it would be good if we could get some feedback from the project maintainers on these questions. Do you have any thoughts? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/924#note_9292

2 1

Re: [PATCH v2 0/8] MR924: ntdll: Add support for DOS file attributes
by Erich Hoover (＠ehoover) Sept. 26, 2022

Sept. 26, 2022

On Mon Sep 26 21:52:01 2022 +0000, Joel Holdsworth wrote: > That sounds like an nice easy path forward. > One practical question. How do I make the test case `todo_wine` in some > cases, an not in others? Do I just have to comment out the test? Or is > there a trick to indicate that inconsistency between plaforms is expected? Like this: ``` todo_wine_if (my_todo_flag) ok (returned_value == expected_value, "expected %x, got %x\n", expected_value, returned_value); ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/924#note_9331

1 0

Re: [PATCH v2 0/8] MR924: ntdll: Add support for DOS file attributes
by Joel Holdsworth (＠jhol) Sept. 26, 2022

Sept. 26, 2022

On Mon Sep 26 21:41:12 2022 +0000, Erich Hoover wrote: > @jhol I believe that @zfigura's suggestion to just merge the first four > patches is in-line with what AJ has previously said. If I had to > summarize his comments, I would say that they are to: > 1. move the code out of ports and into file (already done) > 2. submit the initial request for the support of one key platform > (Linux, first four patches) > 3. make sure the "key platform" support is extensible (already done) > 4. submit additional requests for each additional platform, one at a time > If you want to add a "fallback" behavior (which I think is reasonable), > then I would suggest that that be treated as an "additional platform" > after you have the initial support in place. Others might have a > different opinion. That sounds like an nice easy path forward. One practical question. How do I make the test case `todo_wine` in some cases, an not in others? Do I just have to comment out the test? Or is there a trick to indicate that inconsistency between plaforms is expected? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/924#note_9330

1 0

[PATCH 0/1] MR934: wininet: Set thread name for collect_connections_proc.
by Brendan Shanks (＠bshanks) Sept. 26, 2022

Sept. 26, 2022

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

3 2

Re: [PATCH v2 0/8] MR924: ntdll: Add support for DOS file attributes
by Erich Hoover (＠ehoover) Sept. 26, 2022

Sept. 26, 2022

On Mon Sep 26 20:25:30 2022 +0000, Joel Holdsworth wrote: > Hi Zebediah - thanks for taking a look. > I don't mind narrowinging the commit series down. > This patch set is mainly trying to get these attribute flags working: > * `FILE_ATTRIBUTE_HIDDEN` > * `FILE_ATTRIBUTE_SYSTEM` > * `FILE_ATTRIBUTE_READONLY` (to a lesser extent - because this is > already quite well represented by UNIX access permissions) > The trouble is that while we want to seamlessly integrate with the > underlying filesystems, the availability of different methods varies > between operating systems and filesystems. This version of the patch set > offers three strategies, and I found a two more possible methods that > should be added today > ([1](https://man7.org/linux/man-pages/man2/ioctl_iflags.2.html) > [2](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/… > ). > The code attempts to store the flags by all available methods at once > for a given file, and ORs the flags together from any available source, > in the hopes we can deliver the most complete coverage to the user. > However, because there is no fallback method, it is currenly not > possible to guaruantee that the attributes will always be stored and > retrieved correctly in all scenaries. > If we only include the first four patches, the patch set will only > support storage in Samba-formatted Extended File Attributes. If we > unmark the associated test cases as `todo_wine`, the test will break on > certain operating systems or certain mount flag choices. There is no > support for Extended Attributes on FreeBSD or NetBSD, for example, and > the MacOS Extended Atrribute APIs differ from the Linux ones. > One approach is to fall back to using a `.dosattributes` directory when > no other storage method is available, and store the attributes in files > inside there. However, I didn't want to implement this functionality > before having a conversation with the Wine project developers. > I have been in conversation with @ehoover in the last couple of days > concerning his work on Junction Points, which is a related topic to DOS > attributes, and also causes issues for Msys2 in its own right. His > strategy is to store the required metadata in a [`.REPARSE_POINT` hidden directory](https://github.com/wine-staging/wine-staging/blob/master/patches…. > There is also the storage of [NT extended-attribute > (EA)](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/n…) > values to consider, when we move toward a non-stub implementation of > this feature. > Perhaps it would be preferable to produce a design that can be encompass > all these issues. > Do we need to resolve this design question here and now? Or can we just > proceed with Linux-only Extended Attributes in the short term? > I think it would be good if we could get some feedback from the project > maintainers on these questions. Do you have any thoughts? @jhol I believe that @zfigura's suggestion to just merge the first four patches is in-line with what AJ has previously said. If I had to summarize his comments, I would say that they are to: 1. move the code out of ports and into file (already done) 2. submit the initial request for the support of one key platform (Linux, first four patches) 3. make sure the "key platform" support is extensible (already done) 4. submit additional requests for each additional platform, one at a time If you want to add a "fallback" behavior (which I think is reasonable), then I would suggest that that be treated as an "additional platform" after you have the initial support in place. Others might have a different opinion. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/924#note_9327

1 0

Re: [PATCH v2 0/8] MR927: wmvcore: Use more IWMSyncReader methods in the async reader. - approved
by Alexandre Julliard (＠julliard) Sept. 26, 2022

Sept. 26, 2022

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/927

1 0

Re: [PATCH v2 0/1] MR931: dbghelp: Fix local scope reset upon module unloading. - approved
by Alexandre Julliard (＠julliard) Sept. 26, 2022

Sept. 26, 2022

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/931

1 0