- Wine-gitlab - list.winehq.org

[PATCH 0/2] MR10038: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails.
by Kun Yang (＠yangkun) 06 Feb '26

06 Feb '26

Logs: When CreateDIBSection does not return a valid hbitmap, the source image is lost that only masked icon is shown in imagelist. Signed-off-by: Kun Yang <yangkun(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10038

3 7

[PATCH 0/1] MR10040: inkobj: Correct install path.
by Alistair Leslie-Hughes (＠alesliehughes) 06 Feb '26

06 Feb '26

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

2 1

Re: [PATCH v2 0/1] MR10034: comctl32: Fix the bug when the cInitial is too large which lead to CreateDIBSection fails. - closed
by Kun Yang (＠yangkun) 06 Feb '26

06 Feb '26

This merge request was closed by Kun Yang. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10034

1 0

[PATCH v5 0/1] MR10036: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons.
by Tim Clem (＠tclem) 05 Feb '26

05 Feb '26

Sidesteps an issue cause by some apps having an inaccurate size for the resource in the GRPICONDIR size ; CreateIconFromResourceEx handles that case, but the old CGImage path would fault if the GRPICONDIR size was too large. --- It seems that some apps have different sizes in the GRPICONDIR and the IMAGE_RESOURCE_DATA_ENTRY. winemenubuilder has had a workaround for this since 2014 - see c205e6800a63a5df9960d8484a2e67687d53bc50. The size difference is great enough in some situations (e.g. Brotato) that the attempt read the resource may fault, but that's only because we passed the PNG data over to the Unix side of winemac.drv directly, and used CG methods to deal with it, which will attempt to copy in the entire array of bytes. If we use CreateIconFromResourceEx instead, for all cases (it can handle pngs), we do not fault, since that method does not attempt to copy the entire resource size. The original mailing list discussion about the winemenubuilder patch is [here](https://marc.info/?l=wine-patches&m=140903555724711&w=2). Huge thanks to @bshanks for spotting that patch. This has apparently always been faulting for some apps, but only became an issue after !10032. The subsequent syscall fault unwinds out of the pthread_once that !10032 added, so future threads that wind up there will hang. -- v5: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons. https://gitlab.winehq.org/wine/wine/-/merge_requests/10036

3 3

Re: [PATCH v2 0/2] MR10035: kernelbase: Don't write *result on async NtWriteFile returns. - approved
by Alexandre Julliard (＠julliard) 05 Feb '26

05 Feb '26

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

1 0

Re: [PATCH v2 0/2] MR10014: ntdll, mountmgr.sys: Report free space for "important" data on macOS. - approved
by Alexandre Julliard (＠julliard) 05 Feb '26

05 Feb '26

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

1 0

[PATCH v4 0/1] MR10036: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons.
by Tim Clem (＠tclem) 05 Feb '26

05 Feb '26

Sidesteps an issue cause by some apps having an inaccurate size for the resource in the GRPICONDIR size ; CreateIconFromResourceEx handles that case, but the old CGImage path would fault if the GRPICONDIR size was too large. --- It seems that some apps have different sizes in the GRPICONDIR and the IMAGE_RESOURCE_DATA_ENTRY. winemenubuilder has had a workaround for this since 2014 - see c205e6800a63a5df9960d8484a2e67687d53bc50. The size difference is great enough in some situations (e.g. Brotato) that the attempt read the resource may fault, but that's only because we passed the PNG data over to the Unix side of winemac.drv directly, and used CG methods to deal with it, which will attempt to copy in the entire array of bytes. If we use CreateIconFromResourceEx instead, for all cases (it can handle pngs), we do not fault, since that method does not attempt to copy the entire resource size. The original mailing list discussion about the winemenubuilder patch is [here](https://marc.info/?l=wine-patches&m=140903555724711&w=2). Huge thanks to @bshanks for spotting that patch. This has apparently always been faulting for some apps, but only became an issue after !10032. The subsequent syscall fault unwinds out of the pthread_once that !10032 added, so future threads that wind up there will hang. -- v4: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons. https://gitlab.winehq.org/wine/wine/-/merge_requests/10036

3 3

[PATCH v3 0/1] MR10036: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons.
by Tim Clem (＠tclem) 05 Feb '26

05 Feb '26

Sidesteps an issue cause by some apps having an inaccurate size for the resource in the GRPICONDIR size ; CreateIconFromResourceEx handles that case, but the old CGImage path would fault if the GRPICONDIR size was too large. --- It seems that some apps have different sizes in the GRPICONDIR and the IMAGE_RESOURCE_DATA_ENTRY. winemenubuilder has had a workaround for this since 2014 - see c205e6800a63a5df9960d8484a2e67687d53bc50. The size difference is great enough in some situations (e.g. Brotato) that the attempt read the resource may fault, but that's only because we passed the PNG data over to the Unix side of winemac.drv directly, and used CG methods to deal with it, which will attempt to copy in the entire array of bytes. If we use CreateIconFromResourceEx instead, for all cases (it can handle pngs), we do not fault, since that method does not attempt to copy the entire resource size. The original mailing list discussion about the winemenubuilder patch is [here](https://marc.info/?l=wine-patches&m=140903555724711&w=2). Huge thanks to @bshanks for spotting that patch. This has apparently always been faulting for some apps, but only became an issue after !10032. The subsequent syscall fault unwinds out of the pthread_once that !10032 added, so future threads that wind up there will hang. -- v3: winemac.drv: Unconditionally use CreateIconFromResourceEx for app icons. https://gitlab.winehq.org/wine/wine/-/merge_requests/10036

4 7

[PATCH v2 0/1] MR10036: winemac.drv: Attempt to correct the size of icon resources.
by Tim Clem (＠tclem) 05 Feb '26

05 Feb '26

It seems that some apps have different sizes in the GRPICONDIR and the IMAGE_RESOURCE_DATA_ENTRY. winemenubuilder has had the same workaround since 2014 - see c205e6800a63a5df9960d8484a2e67687d53bc50. --- The size difference is great enough in some situations (e.g. Brotato) that the attempt read the resource may fault. The original mailing list discussion about the winemenubuilder patch is [here](https://marc.info/?l=wine-patches&m=140903555724711&w=2). Huge thanks to @bshanks for spotting that patch. This has apparently always been faulting for some apps, but only became an issue after !10032. The subsequent syscall fault unwinds out of the pthread_once that !10032 added, so future threads that wind up there will hang. -- v2: winemac.drv: Attempt to correct the size of icon resources. https://gitlab.winehq.org/wine/wine/-/merge_requests/10036

4 9

[PATCH 0/1] MR10036: winemac.drv: Attempt to correct the size of icon resources.
by Tim Clem (＠tclem) 05 Feb '26

05 Feb '26

It seems that some apps have different sizes in the GRPICONDIR and the IMAGE_RESOURCE_DATA_ENTRY. winemenubuilder has had the same workaround since 2014 - see c205e6800a63a5df9960d8484a2e67687d53bc50. --- The size difference is great enough in some situations (e.g. Brotato) that the attempt read the resource may fault. The original mailing list discussion about the winemenubuilder patch is [here](https://marc.info/?l=wine-patches&m=140903555724711&w=2). Huge thanks to @bshanks for spotting that patch. This has apparently always been faulting for some apps, but only became an issue after !10032. The subsequent syscall fault unwinds out of the pthread_once that !10032 added, so future threads that wind up there will hang. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10036

3 2