October 2025 - Wine-GitLab - list.winehq.org

[PATCH v2 0/7] MR9136: mshtml: Use a common object implementation for collection enumerators.
by Gabriel Ivăncescu Oct. 13, 2025

Oct. 13, 2025

-- v2: mshtml: Use the common object implementation for HTMLAttributeCollection mshtml: Use the common object implementation for HTMLStyleSheetsCollection mshtml: Use the common object implementation for HTMLRectCollection mshtml: Use the common object implementation for HTMLSelectElement enumerator. mshtml: Use the common object implementation for HTMLFormElement enumerator. mshtml: Use the common object implementation for HTMLDOMChildrenCollection mshtml: Use a common object implementation for HTMLElementCollection https://gitlab.winehq.org/wine/wine/-/merge_requests/9136

2 11

[PATCH v2 0/1] MR9090: ntdll: Use Mach COW for write watches support on macOS.
by Marc-Aurel Zent (＠mzent) Oct. 13, 2025

Oct. 13, 2025

This uses the Mach COW mechanism to implement writewatch functionality. Below is the same micro-benchmark @gofman used in his [UFFD MR](https://gitlab.winehq.org/wine/wine/-/merge_requests/7871). ``` Parameters: - number of concurrent threads; - number of pages; - delay between reading / resetting write watches (ms) - random (1) or sequentual (0) page write access; - reset with WRITE_WATCH_FLAG_RESET in GetWriteWatch (1) or in a separate ResetWriteWatch call (0). Result is in the form of <average write to page time, ns> / <average GetWriteWatch() time, mcs> Parameters Windows Mach COW Fallback 6 1080 3 1 1 897 / 80 371 / 12634 66202 / 186 6 1080 3 1 0 855 / 87 369 / 12637 66766 / 187 8 8192 3 1 1 6526 / 268 627 / 113263 111053 / 485 8 8192 3 1 0 1197 / 509 623 / 113810 122921 / 489 8 8192 1 1 1 1227 / 412 636 / 118930 150628 / 388 8 8192 1 1 0 5721 / 144 631 / 120538 146392 / 384 8 64 1 1 1 572 / 7 490 / 1078 1000 / 89 8 64 1 1 0 530 / 13 500 / 1075 1167 / 77 ``` This was all on the same M2 Max machine with Windows being win11 on ARM in a VM running the x64 binary emulated and otherwise Wine through Rosetta with and without this MR. Unlike UFFD which is always better than fallback and comparable to the Windows performance, here good average write to page time is traded for bad average `GetWriteWatch()` time (pretty much in equal ratios). However in real world applications (like the FFXIV + Dalamud mod framework/loader use case) the startup time is reduced from about 25.5s to 23.6s with this change from a cold start, including loading a modern dotnet 9 runtime into the game process and initializing a complex mod collection, with a fairly high GC pressure. This is probably because the `GetWriteWatch()` calls the GC does mostly happen concurrently, whereas in Wines fallback implementation running threads are interrupted and often wait on the global virtual lock in Wine while the segfault is handled and parallel accesses to write watched memory and other VM operations are blocked. Another advantage is that `VPROT_WRITEWATCH` can be used then for other purposes in the future and also Rosetta being a bit finicky sometimes with reported protections with the current implementation, but behaved always as expected so far in my testing with the new one. On native ARM64 the `VM_PROT_COPY`/`SM_COW` mechanism works also as expected on native 16k pages (not that this matters much at the moment). `GetWriteWatch()` with the reset flag also does not need to be transactional (unlike UFFD), since only marked pages are reset here and not the entire range. -- v2: ntdll: Use Mach COW for write watches support on macOS. https://gitlab.winehq.org/wine/wine/-/merge_requests/9090

4 9

[PATCH 0/6] MR9166: win32u: Implement vulkan memory export / import through host fds.
by Rémi Bernon Oct. 13, 2025

Oct. 13, 2025

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

2 13

[PATCH v10 0/6] MR9147: rometadata: Implement CIL assembly/metadata reader + some IMetaDataTables methods.
by Vibhav Pant (＠vibhavp) Oct. 13, 2025

Oct. 13, 2025

-- v10: rometadata: Implement IMetaDataTables::{GetColumn, GetColumnInfo}. rometadata/tests: Add tests for IMetaDataTables::{GetColumnInfo, GetColumn}. rometadata: Implement IMetaDataTables::Get{String,Blob,Guid}. rometadata: Implement IMetaDataTables::GetRow. rometadata: Implement IMetaDataTables::GetTableInfo. rometadata: Implement IMetaDataTables::{Get{String,Blob,Guid,UserString}HeapSize, GetNumTables}. https://gitlab.winehq.org/wine/wine/-/merge_requests/9147

3 8

[PATCH 0/1] MR9167: mmdevapi/tests: Use wine_dbgstr_longlong().
by Sven Baars (＠sbaars) Oct. 13, 2025

Oct. 13, 2025

Fixes compiler warnings on older systems. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9167

3 2

Re: [PATCH v9 0/6] MR9147: rometadata: Implement CIL assembly/metadata reader + some IMetaDataTables methods.
by Vibhav Pant (＠vibhavp) Oct. 13, 2025

Oct. 13, 2025

v9: * Address feedback. * Remove `tables_set_key_idx`, and calculate the primary key index in `assembly_get_table` instead. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9147#note_118376

1 0

Re: [PATCH v9 0/6] MR9147: rometadata: Implement CIL assembly/metadata reader + some IMetaDataTables methods.
by Vibhav Pant (＠vibhavp) Oct. 13, 2025

Oct. 13, 2025

On Mon Oct 13 09:20:43 2025 +0000, Hans Leidekker wrote: > If you make this an array of struct metadata_stream and add the name to > struct metadata_stream you don't need the streams array in assembly_parse_headers(). But then wouldn't we need to always iterate through the array with `strcmp` to get a particular stream (for instance, in `assembly_get_heap_size`, `assembly_get_{string, blob, guid}`)? The spec doesn't say that streams need to appear in a certain order, so we wouldn't be able to use fixed indices to this array. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9147#note_118375

1 0

Re: [PATCH v9 0/6] MR9147: rometadata: Implement CIL assembly/metadata reader + some IMetaDataTables methods.
by Vibhav Pant (＠vibhavp) Oct. 13, 2025

Oct. 13, 2025

On Mon Oct 13 09:20:43 2025 +0000, Hans Leidekker wrote: > This is static data, it should be possible to encode this without an > init function. Sure. I have removed this and the associated `key_idx` field in the static schema data. Instead, we just find the primary key column in `assembly_get_table` now. I didn't want to hardcode the primary key index in the schema macros, because I wanted to keep the macros as self-descriptive as possible (through the `*_PRIMARY` column macros, in this case). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9147#note_118374

1 0

Re: [PATCH v9 0/6] MR9147: rometadata: Implement CIL assembly/metadata reader + some IMetaDataTables methods.
by Vibhav Pant (＠vibhavp) Oct. 13, 2025

Oct. 13, 2025

On Mon Oct 13 09:20:43 2025 +0000, Hans Leidekker wrote: > Using an offset variable would be cleaner. Sure, thanks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9147#note_118373

1 0

Re: [PATCH v9 0/6] MR9147: rometadata: Implement CIL assembly/metadata reader + some IMetaDataTables methods.
by Vibhav Pant (＠vibhavp) Oct. 13, 2025

Oct. 13, 2025

On Mon Oct 13 09:20:43 2025 +0000, Hans Leidekker wrote: > What if assembly->stream_strings.size == 1? This could be written > without the padding variable. Hm, so II.24.2.3 mandates that the first string should always be `\0`, and II.24.2.2 says that stream sizes should be a multiple of 4. Nonetheless, this should still handle a string heap with a single NUL entry, so rewritten this to subtract padding bytes as long as `stream_strings.size > 1`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9147#note_118367

1 0