June 2022 - Wine-Devel - list.winehq.org

Re: [PATCH v2 0/3] MR199: jscript: Set and Map object fixes - approved

by Alexandre Julliard (＠julliard)

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

June 7, 2022

Re: [PATCH v2 0/3] MR198: ntdll: Fix unwinding on ARM in PE mode - approved

by Alexandre Julliard (＠julliard)

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

June 7, 2022

Re: [PATCH v2 0/1] MR194: mmdevapi: Remove android from default driver list. - approved

by Alexandre Julliard (＠julliard)

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

June 7, 2022

Re: [PATCH v2 0/11] MR193: wineandroid: PE conversion - approved

by Alexandre Julliard (＠julliard)

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

June 7, 2022

[PATCH 1/1] server: Hold socket reference in sock_poll_event().

by Paul Gofman

From: Paul Gofman <pgofman(a)codeweavers.com> --- server/sock.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/server/sock.c b/server/sock.c index 77a88a7fcf7..48ebf59ed88 100644 --- a/server/sock.c +++ b/server/sock.c @@ -1109,6 +1109,8 @@ static void sock_poll_event( struct fd *fd, int event ) int error = 0; assert( sock->obj.ops == &sock_ops ); + grab_object( &sock->obj ); + if (debug_level) fprintf(stderr, "socket %p select event: %x\n", sock, event); @@ -1188,6 +1190,7 @@ static void sock_poll_event( struct fd *fd, int event ) complete_async_polls( sock, event, error ); sock_reselect( sock ); + release_object( &sock->obj ); } static void sock_dump( struct object *obj, int verbose ) -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/202

June 7, 2022

[PATCH 0/1] MR202: server: Hold socket reference in sock_poll_event().

by Paul Gofman (＠gofman)

The socket may get released if the sock_poll_event() is inspired by closing socket. Here is a WIP test (where I am trying to test unrelated things) which causes assert in wineserver on closing socket (when server is trying to use already freed socket): https://gist.github.com/gofman/cc78a07ed58f6d02ff863388d5992acb -- https://gitlab.winehq.org/wine/wine/-/merge_requests/202

June 7, 2022

Re: [PATCH 0/5] MR201: ntdll: Implement RtlSetUserValueHeap.

by Zebediah Figura

On 6/7/22 14:46, Rémi Bernon (@rbernon) wrote: > On Tue Jun 7 19:33:23 2022 +0000, **** wrote: >> Zebediah Figura replied on the mailing list: >> ``` >> On 6/7/22 13:33, Rémi Bernon wrote: >>> typedef struct >>> { >>> + SIZE_T __pad[sizeof(SIZE_T) / sizeof(DWORD)]; >>> struct list entry; /* entry in heap large blocks >> list */ >>> SIZE_T data_size; /* size of user data */ >>> SIZE_T block_size; /* total size of virtual >> memory block */ >>> - DWORD pad[2]; /* padding to ensure 16-byte >> alignment of data */ >>> + void *user_value; >>> DWORD size; /* fields for compatibility >> with normal arenas */ >>> DWORD magic; /* these must remain at the >> end of the structure */ >>> } ARENA_LARGE; >> Doesn't this end up wasting space on 64 bits? I.e. the structure is >> already aligned to a multiple of 16 bytes without any padding. >> (Also, somewhat out of curiosity, why move the member?) >> ``` > It makes the large block header size match native size, of `8 * sizeof(void *)`. > > Moving the member makes the struct layout closer to SUBHEAP, and I think the same struct could be use for both later. Native has a concept of heap region, which seems to correspond to both large blocks and SUBHEAP at the same time. For instance only growable heap let you allocate large blocks. > Okay, makes sense. In the future I guess it'd be nice to see that spelled out in the patch, or perhaps ideally as separate patches; that'd help make things clearer.

June 7, 2022

Re: [PATCH 0/5] MR201: ntdll: Implement RtlSetUserValueHeap.

by Rémi Bernon

On Tue Jun 7 19:33:23 2022 +0000, **** wrote: > Zebediah Figura replied on the mailing list: > ``` > On 6/7/22 13:33, Rémi Bernon wrote: > > typedef struct > > { > > + SIZE_T __pad[sizeof(SIZE_T) / sizeof(DWORD)]; > > struct list entry; /* entry in heap large blocks > list */ > > SIZE_T data_size; /* size of user data */ > > SIZE_T block_size; /* total size of virtual > memory block */ > > - DWORD pad[2]; /* padding to ensure 16-byte > alignment of data */ > > + void *user_value; > > DWORD size; /* fields for compatibility > with normal arenas */ > > DWORD magic; /* these must remain at the > end of the structure */ > > } ARENA_LARGE; > Doesn't this end up wasting space on 64 bits? I.e. the structure is > already aligned to a multiple of 16 bytes without any padding. > (Also, somewhat out of curiosity, why move the member?) > ``` It makes the large block header size match native size, of `8 * sizeof(void *)`. Moving the member makes the struct layout closer to SUBHEAP, and I think the same struct could be use for both later. Native has a concept of heap region, which seems to correspond to both large blocks and SUBHEAP at the same time. For instance only growable heap let you allocate large blocks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/201#note_1655

June 7, 2022

Re: [PATCH 5/5] ntdll: Implement RtlSetUserValueHeap.

by Zebediah Figura

On 6/7/22 13:33, Rémi Bernon wrote: > typedef struct > { > + SIZE_T __pad[sizeof(SIZE_T) / sizeof(DWORD)]; > struct list entry; /* entry in heap large blocks list */ > SIZE_T data_size; /* size of user data */ > SIZE_T block_size; /* total size of virtual memory block */ > - DWORD pad[2]; /* padding to ensure 16-byte alignment of data */ > + void *user_value; > DWORD size; /* fields for compatibility with normal arenas */ > DWORD magic; /* these must remain at the end of the structure */ > } ARENA_LARGE; Doesn't this end up wasting space on 64 bits? I.e. the structure is already aligned to a multiple of 16 bytes without any padding. (Also, somewhat out of curiosity, why move the member?)

June 7, 2022

Re: [PATCH 7/8] mshtml: Check for valid XML Content-Type for responseXML in IE10+ modes.

by Gabriel Ivăncescu

On 07/06/2022 20:16, Jacek Caban wrote: > On 6/6/22 20:21, Gabriel Ivăncescu wrote: >> On 06/06/2022 20:40, Jacek Caban wrote: >>> On 6/6/22 14:24, Gabriel Ivăncescu wrote: >>>> For some reason, Gecko returns an XML document here, but native follows >>>> the spec. >>> >>> >>> That doesn't really make sense, Gecko is not involved because we >>> currently use msxml instead of Gecko here. I guess you're referring >>> to your future patches, in which case the question is what's "some >>> reason"? Looking at Gecko sources, it returns XML document only for >>> XML_HTTP_RESPONSE_TYPE_DEFAULT and XML_HTTP_RESPONSE_TYPE_DOCUMENT >>> response type. What's wrong with that? >>> >>> >>> Similar question applies to overrideMimeType, why can't we let Gecko >>> handle that? >>> >>> >>> Jacek >>> >> >> I meant if we use Gecko's responseXML to check whether it's NULL or >> not. For "default" case (no override), Gecko returns a non-NULL xml >> doc, even if Content-Type is not valid the way IE treats it. So we >> can't use it to check this (I tried it first since it's simpler). >> >> It does do the right thing with overrideMimeType, but if we use it, >> we'll override *any* content type, which is not good either. Well at >> least not good enough to match native IE. > > > The whole thing seems to me like working around a problem somewhere > else. My guess would be nsio.c, which has hacks for things like > GetContentType(), but it's hard to tell without looking deeper. Did you > rule that out somehow? > > > Jacek > I haven't looked into that, I wasn't aware it affects XMLHttpRequests. Skimming through it, it doesn't look like it would affect it (text/html is invalid in IE, not sure if Gecko treats it as valid XML to parse), but I'll investigate it more tomorrow.

June 7, 2022