May 2026 - Wine-GitLab - list.winehq.org

[PATCH v2 0/1] MR10858: Draft: vbscript: Register IDispatch as the class typeinfo's parent and lay non-default funcs first.
by Francis De Brabandere (＠francisdb) May 14, 2026

May 14, 2026

build_class_typeinfo now adds IDispatch as the implicit base via AddRefTypeInfo + AddImplType so the resulting typeinfo reports cImplTypes == 1 and returns the IDispatch typeinfo via GetRefTypeOfImplType -> GetRefTypeInfo, matching native. Compile-time slot 0 is reserved for the default getter/method, so build_class_typeinfo previously emitted the default at FUNCDESC index 0 ahead of declaration-order members. Native lays out non-default funcs first and places the default last. Iterate desc->funcs[1..N] before desc->funcs[0] so 'Public Sub method' lands at index 0 with INVOKE_FUNC and 'Public Default Property Get defprop' lands last. Drop the corresponding todo_wine markers from test_vbdisp_typeinfo; together with the matching oleaut32 changes (cbSizeVft accounting and the GetFuncDesc bound for TKIND_DISPATCH built via ICreateTypeLib2) the four todos and the GetFuncDesc(cFuncs) probe pass on Wine. This requires !10851, !10856, !10857 to be merged first -- v2: vbscript: Register IDispatch as the class typeinfo's parent and lay non-default funcs first. https://gitlab.winehq.org/wine/wine/-/merge_requests/10858

2 1

[PATCH 0/1] MR10892: ntdll/unix: use localtime_r() instead just localtime()
by Benjamin Fischer (＠bfis) May 14, 2026

May 14, 2026

At least for glibc: localtime() calls always check for timezone configuration changes which usually includes a stat syscall, localtime_r() does not. # Explanation At least for glibc, every call of `localtime()` will internally check for (and react to) changes of the timezone: either the `TZ` environment variable (if set) or changes to a used file, typically `/etc/localtime` - the latter causes a 'stat' syscall. In contrast, calls to `localtime_r()` are faster because they don't check for such changes (and also wont update `tzname`, `timezone`, `daylight` global variables). This behavior is extremely poorly documented (on glibc side) such that people regularly rediscover it, often because of the performance impact. # Consequences of this change - for `weekday_to_mday()` and `find_dst_change()`: - this may actually prevent potential issues, if the timezone were to be changed during these search loops - performance may improve, but is likely irrelevant/unnoticeable since this is rarely running code (as far as i can tell) - for `get_timezone_info()`: - it massively improves performance: `ftime` and `time` calls (of MSVCRT) will eventuall call this function, thus incur the massive syscall overhead - after the first use, the timezone is not *automatically* updated when changed via either: - changing the `TZ` environment variable of the running process - changing the timezone information file (usually `/etc/localtime`) and it was actually used e.g. typically when `TZ` is unset Personally, the potential performance gains are worth the limitation that a timezone change of the system will only be effective after application restart. But his could understandably be a point of contention. # Alternative Workarounds The performance issues of the `localtime()` call in the hotpath of `get_timezone_info()` can be: - mitigate for `time()` calls: by not querying timezone info - see upcoming MR TBD - partially mitigate by setting the `TZ` environment variable, but: - in many distros it is not set by default - the value of the variable is used by both the Unix C runtime (e.g. glibc) and MSVCRT and their supported format are not identical, so setting the correct value may be more difficult than usual or even impossible - when using `TZ=:/etc/localtime`, a special format for glibc, the information is still initally read from `/etc/localtime` but not checked for freshness on every subsequent call via stat - but this format is not understood by MSVCRT, thus breaking stuff there. # Origin of Discovery I've a private application that typically is running fairly well, but during certain workloads it becomes sluggish and downright unusable. I took some profiles with `perf` and found fairly clean culprit with `localtime()` and its stat syscall, which I measure the rate for: Under normal conditions I have about 200 per second and during the problematic phases it staturated at about 100k per second. I tracked the origin of call down to `_time64` -> `_ftime64` -> ... -> `get_timezone_info()` by matching callstack information with the list of exported symbols of the involved *.dll files. # Beyond `localtime_r()` Generally speaking, there are also a few opportunities to use _r variants of these time related functions on the Unix side of wine, e.g. for `gmtime()` in `get_zomezone_info()`. Some of such changes could also improve performance, but likely not to the same degree as getting rid of a entire syscall by switching from `localtime()` to `localtime_r()`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10892

3 3

[PATCH 0/2] MR10898: vbscript: Preserve subnormal doubles in numeric literal parsing.
by Francis De Brabandere (＠francisdb) May 14, 2026

May 14, 2026

Literals such as 1e-309 were rounded to zero because pow(10, 309) overflows to infinity, making `d / pow(10, -exp)` equal to d / inf = 0. Split the multiplication so the intermediate value stays in the representable range, which lets the final product reach the IEEE 754 subnormal range like native. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10898

2 2

[PATCH 0/2] MR10897: vbscript: Allow Class declarations inline after Dim/Sub separated by ':'.
by Francis De Brabandere (＠francisdb) May 14, 2026

May 14, 2026

ClassDeclaration was only allowed at the top SourceElement level, so any prior statement on the same line caused err 1002 instead of either parsing successfully or, for a name collision, err 1041. Treat ClassDeclaration as a SimpleStatement matching the FunctionDecl pattern: it produces a STAT_CLASS statement that registers the class with the parser at compile time and errors out if the declaration is not at script global scope. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10897

2 2

[PATCH v2 0/1] MR10896: vbscript: Fix crash on fixed-size Dim array inside Execute called from a local scope.
by Francis De Brabandere (＠francisdb) May 14, 2026

May 14, 2026

Execute pre-registers Dim variables in the caller's dynamic_vars when invoked from a Sub or Function, but interp_dim's FUNC_GLOBAL path only looked them up in the script object, hitting an assertion when the OP_dim instruction ran for a fixed-size array. -- v2: vbscript: Fix crash on fixed-size Dim array inside Execute called from a local scope. https://gitlab.winehq.org/wine/wine/-/merge_requests/10896

2 1

[PATCH 0/2] MR10894: ws2_32: Return WSAENOTSOCK instead of WSAENOTSUPP from select().
by Paul Gofman (＠gofman) May 14, 2026

May 14, 2026

That helps War Thunder which otherwise may complain that select() returned 10045 in a message box when going in game. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10894

3 4

Re: [PATCH v26 0/3] MR10603: win32u/freetype: Fix tmExternalLeading for CFF fonts. - approved
by Arie Miller (＠Arimil) May 14, 2026

May 14, 2026

This merge request was approved by Arie Miller. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10603

1 0

[PATCH 0/2] MR10891: Use typographic subfamily name (nameID 17) for ENUMLOGFONTEXW.elfStyle.
by Ivan Lyugaev (＠valy) May 14, 2026

May 14, 2026

Test program: https://drive.google.com/drive/folders/15Cgp_tSKT9gRijh-4-_JBl8BegZvRoLX?us… EnumFontFamiliesEx for OTF fonts returns the value Typographic Subfamily name (id 17) in the ENUMLOGFONTEXW.elfStyle parameter. For TTF fonts, it returns Font Subfamily name (id 2). Below are the results of running the test program: Windows: .\main.exe .\wine_test_typographic_subfamily.otf "WineTestTypographicSubfamilyOTF" familyName: WineTestTypographicSubfamilyOTF styleName: Base .\main.exe .\wine_test_typographic_subfamily.ttf "WineTestTypographicSubfamilyTTF" familyName: WineTestTypographicSubfamilyTTF styleName: Regular Wine with changes: .\main.exe .\wine_test_typographic_subfamily.otf "WineTestTypographicSubfamilyOTF" familyName: WineTestTypographicSubfamilyOTF styleName: Base Wine without changes: .\main.exe .\wine_test_typographic_subfamily.otf "WineTestTypographicSubfamilyOTF" familyName: WineTestTypographicSubfamilyOTF styleName: Regular -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10891

2 2

[PATCH 0/1] MR10365: kernelbase: Add language specific resource support.
by Craig Schulstad (＠NoDakker) May 14, 2026

May 14, 2026

When an application relies upon language specific resources, search for an associated language specific subfolder and subsequent mui file. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10365

3 15

Re: [PATCH v11 0/1] MR10807: kernelbase: Add language resource search functionality
by Craig Schulstad (＠NoDakker) May 14, 2026

May 14, 2026

On Thu May 14 12:20:22 2026 +0000, Alexandre Julliard wrote: > Please don't rebase your patch every day, that's a waste of CI resources. > In any case that's not the right way to implement MUI. It should be > based on the MUI descriptor in the resources, which we already partially > support in kernelbase. The first step would be to write more tests. Alexandre, Okay. I will withdraw my enhancement and leave the site. I will just continue on with keeping my enhancement out on GitHub for any interested people and look forward to the day MUI support fully works in Wine. Regards, Craig -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10807#note_139813

1 0