October 2023 - wine-gitlab

[PATCH 0/2] MR4222: loader: Associate Wine with internet shortcuts.
by Alex Henrie (＠alexhenrie) 29 Oct '23

29 Oct '23

Wine is the only Linux program I am aware of that can open .url files. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4222

2 2

[PATCH 0/1] MR4220: uninstaller: Use CRT allocation functions.
by Alex Henrie (＠alexhenrie) 29 Oct '23

29 Oct '23

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

2 1

[PATCH 0/1] MR4219: msscript: Use CRT allocation functions.
by Alex Henrie (＠alexhenrie) 29 Oct '23

29 Oct '23

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

2 1

[PATCH 0/1] MR4218: find/tests: Use CRT allocation functions.
by Alex Henrie (＠alexhenrie) 29 Oct '23

29 Oct '23

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

2 1

[PATCH v2 0/1] MR4045: kernelbase: Rewrite ExpandEnvironmentStringsA to return ansi string size
by Fabian Maurer (＠DarkShadow44) 29 Oct '23

29 Oct '23

We can't return the unicode string size, this returns sizes to small for multi-byte characters. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54295 -- v2: kernelbase: Rewrite ExpandEnvironmentStringsA to return ansi string size https://gitlab.winehq.org/wine/wine/-/merge_requests/4045

2 2

[PATCH 0/1] MR4212: d3d9: Use CRT allocation functions.
by Alex Henrie (＠alexhenrie) 29 Oct '23

29 Oct '23

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

3 2

[PATCH 0/3] MR4207: gdiplus: Fix GdipAddPathCurve3 curve calculation with offset and nseg variables
by Bartosz Kosiorek (＠gang65) 29 Oct '23

29 Oct '23

The MR is divided to three commits: 1. Extend AddPathCurve3 test with offset and nseg variables 2. Moving main curve implementation from GdipAddPathCurve2 to GdipAddPathCurve3, allow for use offset and nseg variables in GdipAddPathCurve3. The offset and nseg variables, will be used for fixing curve calculation in next commit. 3. Fix GdipAddPathCurve3 curve calculation with offset and nseg variables -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4207

2 3

[PATCH v11 0/3] MR414: fltmgr.sys: Implement FltBuildDefaultSecurityDescriptor
by Alistair Leslie-Hughes (＠alesliehughes) 29 Oct '23

29 Oct '23

Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> -- v11: ntoskrnl.exe: Add FltBuildDefaultSecurityDescriptor test fltmgr.sys: Create import library fltmgr.sys: Implement FltBuildDefaultSecurityDescriptor https://gitlab.winehq.org/wine/wine/-/merge_requests/414

3 4

[PATCH v2 0/1] MR4206: Draft: gdiplus: Check bounding box in GdipIsVisibleRegionPoint.
by Esme Povirk (＠madewokherd) 28 Oct '23

28 Oct '23

I don't think this should be committed so late in the release cycle, but the work others have been doing with point checking functions inspired me to move on this, and I wanted to let folks know what I'm thinking about and get some feedback. Consider it a proof of concept for now. The problem: GdipGetRegionHRgn is expensive. Regardless of how much of the region we actually care about, we must rasterize the entire plane of that region. Currently, we rely on gdi32 to do this, which doesn't provide us with any way to ask for a smaller area. This has been a real problem for applications that work with very large, non-rectangular regions or paths. So it seems to me, the solution will involve writing two functions, one of which is in this MR: a bounding-box calculation for regions, and rasterization. Since the result of rasterization will be short-lived, I think it should always be an array of bytes (which are effectively a bitmap but don't require bitwise operations to work with). The rasterization should be limited to a specific integer rectangle, which in the case of GdipIsVisibleRegionPoint can be 1x1 pixel. We should then be able to eliminate all internal uses of GdipGetRegionHRgn, except when we have to return an HRGN to the application. This would also be useful for implementing anti-aliasing, as we could keep the memory usage down by only rasterizing the part we need for each scanline at a time. My current concerns about what I've written so far: * Although it shouldn't change the behavior, I doubt it's adequately tested, even including the Mono tests. I'd like to ideally test every combine mode in a variety of cases. * This is too clever for its own good. Unfortunately, with the complexity of handling so many combine modes as well as infinities for each region being combined, I think the only available choices are "too clever for its own good" and "20 different special cases that need to be considered manually". Still, I want to make this as simple and easy to follow as possible, within its requirements. -- v2: gdiplus: Check bounding box in GdipIsVisibleRegionPoint. https://gitlab.winehq.org/wine/wine/-/merge_requests/4206

2 1

[PATCH 0/1] MR4206: Draft: gdiplus: Check bounding box in GdipIsVisibleRegionPoint.
by Esme Povirk (＠madewokherd) 28 Oct '23

28 Oct '23

I don't think this should be committed so late in the release cycle, but the work others have been doing with point checking functions inspired me to move on this, and I wanted to let folks know what I'm thinking about and get some feedback. Consider it a proof of concept for now. The problem: GdipGetRegionHRgn is expensive. Regardless of how much of the region we actually care about, we must rasterize the entire plane of that region. Currently, we rely on gdi32 to do this, which doesn't provide us with any way to ask for a smaller area. This has been a real problem for applications that work with very large, non-rectangular regions or paths. So it seems to me, the solution will involve writing two functions, one of which is in this MR: a bounding-box calculation for regions, and rasterization. Since the result of rasterization will be short-lived, I think it should always be an array of bytes (which are effectively a bitmap but don't require bitwise operations to work with). The rasterization should be limited to a specific integer rectangle, which in the case of GdipIsVisibleRegionPoint can be 1x1 pixel. We should then be able to eliminate all internal uses of GdipGetRegionHRgn, except when we have to return an HRGN to the application. This would also be useful for implementing anti-aliasing, as we could keep the memory usage down by only rasterizing the part we need for each scanline at a time. My current concerns about what I've written so far: * Although it shouldn't change the behavior, I doubt it's adequately tested, even including the Mono tests. I'd like to ideally test every combine mode in a variety of cases. * This is too clever for its own good. Unfortunately, with the complexity of handling so many combine modes as well as infinities for each region being combined, I think the only available choices are "too clever for its own good" and "20 different special cases that need to be considered manually". Still, I want to make this as simple and easy to follow as possible, within its requirements. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4206

2 1

2025

2024

2023

2022

wine-gitlab October 2023