Ok, then I assume you'll revert it in today's push? We can abandon this MR, since the subject (my change to VariantCopyInd) is disproved anyway. I'll try to salvage the tests and open a separate MR for the discovered leak once I actually have a fix, but I think I'm going to prioritize finishing some other items first.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/897#note_9458
On Tue Sep 27 20:16:37 2022 +0000, Esme Povirk wrote:
> I really don't think this needs to be a pointer. If there's going to be
> at most 1 entry per uia_node, and it doesn't need to outlive the
> uia_node, you can put the entry in there directly.
> You can use list_init() when creating uia_node and list_empty() to check
> if the entry is being used. (Though list_remove will leave the entry in
> an invalid state, and you'll have to init it again if you want that
> check to work afterwards.)
That'd make sense. I guess we could also apply this to `node_map_list_entry`, and rather than have custom list entry structures for each, just use the `struct uia_node` structure to store the information we need instead.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/908#note_9457
Esme Povirk (@madewokherd) commented about dlls/uiautomationcore/uia_private.h:
>
> HWND hwnd;
> BOOL nested_node;
> + struct list *prov_thread_list_entry;
I really don't think this needs to be a pointer. If there's going to be at most 1 entry per uia_node, and it doesn't need to outlive the uia_node, you can put the entry in there directly.
You can use list_init() when creating uia_node and list_empty() to check if the entry is being used. (Though list_remove will leave the entry in an invalid state, and you'll have to init it again if you want that check to work afterwards.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/908#note_9455
This patch set is based upon [patches from Wine Staging](https://github.com/wine-staging/wine-staging/tree/master/patches/n… by Erich E. Hoover (@ehoover), and implements support for the `SYSTEM`, `HIDDEN` and `READONLY` DOS file attributes. These can implemented in various ways depending upon the capabilities of the operating system and the file system. However, this initial patch-set focusses on just one method: Samba-formatted Extended File Attributes.
Modern filesystems generally support Extended File Attributes - auxiliary blobs of binary data that can be attached to a file. Samba uses the `user.DOSATTRIB` attribute to store DOS attribute information in the form of a hexadecimal value, and this patch-set implements a compatible mechanism.
Support for additional storage methods to increase operating system and filesystem compatibility is planned for later patch submissions.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/946
`mscomctl.ocx` (part of the VB6 common controls) calls `HeapCreate(0x04000000,1,0)`, that flag is the old and undocumented `HEAP_SHARED`.
`HEAP_CreateSystemHeap()` tries to map memory at `0x80000000`, this fails on Wow64 (and probably should for all 32-bit platforms for non-LAA EXEs).
As a workaround, map the memory anywhere if it fails at `0x80000000`.
I wasn't able to find much documentation about `HEAP_SHARED`, it dates back to Win9x and I guess Wine may have needed it for some native DLLs.
It's not clear whether modern Windows really implements any shared heap functionality any more, every 'shared' heap created returns a different pointer (even in the same process). Maybe Wine should remove the functionality too?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/920