- Wine-GitLab - list.winehq.org

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

Re: [PATCH v3 0/4] MR8958: win32u: Fixes for the OpenGL drawables mess.
by Rémi Bernon Oct. 13, 2025

Oct. 13, 2025

On Mon Oct 13 10:09:28 2025 +0000, li xiao wrote: > When I merged this request and submitted win32u: Don't store the window > OpenGL drawables on the DCs.:, I encountered a deadlock while running a > software using wine: 01 a0:err:sync:RtlpWaitForCriticalSection section > 00007F4A4ACC5570 "?" wait timed out in thread 01a0, blocked by 0134, > retrying (60 sec). Before the merger, it's ok. > \ > After this submission : **win32u: Don't store the window OpenGL > drawables on the DCs.The lifecycle of opengl_rrawable is no longer > related to DC,Why is there still** > ```c > struct opengl_drawable *opengl_drawable > ``` > **in DC?** Hi, sorry if this has caused some more issues but if there's a bug please submit a bug report to https://bugs.winehq.org with some more details about it happens and how to reproduce it. Regarding the `opengl_drawable` member in the DC structure, it's still being used for non-Window DCs, like memory DCs, which need to keep a reference on their eventual OpenGL surface. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8958#note_118366

1 0

Re: [PATCH v3 0/4] MR8958: win32u: Fixes for the OpenGL drawables mess.
by li xiao (＠xiaolizai) Oct. 13, 2025

Oct. 13, 2025

When I merged this request and submitted win32u: Don't store the window OpenGL drawables on the DCs.:, I encountered a deadlock while running a software using wine: 01 a0:err:sync:RtlpWaitForCriticalSection section 00007F4A4ACC5570 "?" wait timed out in thread 01a0, blocked by 0134, retrying (60 sec). Before the merger, it's ok. \ After this submission : **win32u: Don't store the window OpenGL drawables on the DCs.The lifecycle of opengl_rrawable is no longer related to DC,Why is there still** ```c struct opengl_drawable *opengl_drawable ``` **in DC?** -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8958#note_118363

1 0

[PATCH v3 0/6] MR9150: comctl32: Remove v6 only exports.
by Zhiyi Zhang (＠zhiyi) Oct. 13, 2025

Oct. 13, 2025

-- v3: comctl32: Remove v6 only exports. comctl32: Remove syslink from comctl32 v5. comctl32: Remove taskdialog from comctl32 v5. comctl32/tests: Test v6 only exports. comctl32: Remove user32 control copies in comctl32 v5. comctl32/tests: Add RegisterClassNameW() tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/9150

3 7

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

Oct. 13, 2025

Hans Leidekker (@hans) commented about dlls/rometadata/assembly.c: > +{ > + const BYTE *ptr; > + ULONG size_len; > + HRESULT hr; > + > + if (idx >= assembly->stream_blobs.size) return E_INVALIDARG; > + ptr = assembly->stream_blobs.start + idx; > + if (FAILED(hr = decode_int(ptr, size, &size_len))) return hr; > + *blob = ptr + size_len; > + return S_OK; > +} > + > +const GUID *assembly_get_guid(const assembly_t *assembly, ULONG idx) > +{ > + idx = (idx - 1) * sizeof(GUID); /* Indices into the GUID heap are 1-based */ > + return idx < assembly->stream_guids.size ? (const GUID *)(assembly->stream_guids.start + idx) : NULL; Using an offset variable would be cleaner. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9147#note_118350

1 0

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

Oct. 13, 2025

Hans Leidekker (@hans) commented about dlls/rometadata/assembly.c: > + break; > + } > + } > + if (FAILED(hr)) return hr; > + /* The stream name is padded to the next 4-byte boundary (ECMA-335 Partition II.24.2.2) */ > + streams_cur += offsetof(struct stream_hdr, name[(streams[j].name_len + 4) & ~3]); > + } > + > + if (assembly->stream_strings.size) > + { > + /* IMetaDataTables::GetStringHeapSize returns the string heap size without the nul byte padding. */ > + const BYTE *ptr = assembly->stream_strings.start + assembly->stream_strings.size - 1; > + ULONG padding; > + > + for (padding = 0; !ptr[0] && !ptr[-1]; ptr--, padding++) /* nothing */; > + assembly->stream_strings.size -= padding; What if assembly->stream_strings.size == 1? This could be written without the padding variable. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9147#note_118348

1 0

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

Oct. 13, 2025

Hans Leidekker (@hans) commented about dlls/rometadata/assembly.c: > + ULONG i; > + > + for (i = 0; i < TABLE_MAX; i++) > + { > + struct table_schema *schema = table_schemas[i]; > + ULONG j; > + > + for (j = 0; j < schema->columns_len; j++) > + { > + if (schema->columns[j].primary_key) > + { > + schema->key_idx = j; > + break; > + } > + } > + } This is static data, it should be possible to encode this without an init function. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9147#note_118349

1 0

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

Oct. 13, 2025

Hans Leidekker (@hans) commented about dlls/rometadata/assembly.c: > + UINT32 size; > + const BYTE *start; > +}; > + > +struct assembly > +{ > + HANDLE file; > + HANDLE map; > + const BYTE *data; > + UINT64 size; > + > + struct metadata_stream stream_tables; > + struct metadata_stream stream_strings; > + struct metadata_stream stream_blobs; > + struct metadata_stream stream_guids; > + struct metadata_stream stream_user_strings; 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(). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9147#note_118347

1 0

[PATCH v2 0/6] MR9150: comctl32: Remove v6 only exports.
by Zhiyi Zhang (＠zhiyi) Oct. 13, 2025

Oct. 13, 2025

-- v2: comctl32: Remove v6 only exports. comctl32: Remove syslink from comctl32 v5. comctl32: Remove taskdialog from comctl32 v5. comctl32/tests: Test v6 only exports. comctl32: Remove user32 control copies in comctl32 v5. comctl32/tests: Add RegisterClassNameW() tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/9150

2 7

[PATCH v5 0/4] MR9112: XCOPY and COPY should not attempt to copy a file to itself.
by Joe Souza (＠JoeS209) Oct. 13, 2025

Oct. 13, 2025

Current code attempts to copy a file to itself. File is not actually copied; instead, a file sharing error is received. This result is ugly and differs from native. Behavior now appears to be the same as native with changes in this MR . -- v5: cmd: Don't attempt to copy a file to itself. cmd: Reset return_code after successful COPY. https://gitlab.winehq.org/wine/wine/-/merge_requests/9112

2 4

[PATCH v4 0/3] MR9112: XCOPY and COPY should not attempt to copy a file to itself.
by Joe Souza (＠JoeS209) Oct. 13, 2025

Oct. 13, 2025

Current code attempts to copy a file to itself. File is not actually copied; instead, a file sharing error is received. This result is ugly and differs from native. Behavior now appears to be the same as native with changes in this MR . -- v4: cmd: Don't attempt to copy a file to itself. cmd/tests: Add tests for COPY to self. https://gitlab.winehq.org/wine/wine/-/merge_requests/9112

2 4

[PATCH 0/2] MR9164: advapi, ntdll: Add a couple of event tracing stubs.
by Paul Gofman (＠gofman) Oct. 12, 2025

Oct. 12, 2025

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

2 3

[PATCH v3 0/1] MR8988: win32u: change the stretch mode of dst hdc from BlackOnWhite to ColorOnColor...
by Kun Yang (＠yangkun) Oct. 12, 2025

Oct. 12, 2025

win32u: change the stretch mode of dst hdc from BlackOnWhite to ColorOnColor when using StretchBlt in TransparentBlt. In NtGdiTransparentBlt function, the StretchBlt mode of dst hdc is not set. The Default StretchBlt Mode in wine is BlackOnWhite. It is not correct to use this StretchBltMode in TransparentBlt dealing with color bitmap. According to MSDN, it should be converted to ColorOnColor. My test code shows that, the image converted by wine generates a lot of chromatic noise. [test_blt.c](/uploads/26101bc7bdb27400d02c8ff5bf741864/test_blt.c) [test_blt.exe](/uploads/98ee3ab7ce0d590e1511bd8a5fb5a1bb/test_blt.exe) ![source](/uploads/0c56c5e6d1280040ba08cd3dee7acd95/source.bmp) ![result_wrong](/uploads/2076396e069f852914313a8fb86dd5e2/result_wrong.bmp) ![result](/uploads/cf3ec00bf0f0e7f3ea7fe1e2085385d6/result.bmp) -- v3: win32u: change the stretch mode of dst hdc from BlackOnWhite to ColorOnColor when using StretchBlt in TransparentBlt. https://gitlab.winehq.org/wine/wine/-/merge_requests/8988

3 5

[PATCH 0/2] MR9162: shell32: Set SFGAO_HASSUBFOLDER correctly for normal shellfolders.
by Elizabeth Figura (＠zfigura) Oct. 12, 2025

Oct. 12, 2025

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

4 5

[PATCH v8 0/1] MR4878: advpack: Ignore lines that begin with '@' in (Un)RegisterOCXs sections.
by Alex Henrie (＠alexhenrie) Oct. 12, 2025

Oct. 12, 2025

selfreg.c was copied from dlls/msi/tests and load_resource was copied from dlls/setupapi/tests/install.c. Two of the tests are marked todo because Wine currently doesn't support the UnregisterOCXs command, only RegisterOCXs. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56209 -- v8: advpack: Ignore lines that begin with '@' in (Un)RegisterOCXs sections. https://gitlab.winehq.org/wine/wine/-/merge_requests/4878

2 2

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

Oct. 12, 2025

-- v8: 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. https://gitlab.winehq.org/wine/wine/-/merge_requests/9147

2 7

[PATCH v2 0/1] MR411: win32u: Don't load bitmap only TTF fonts without bitmap table.
by Paul Gofman (＠gofman) Oct. 12, 2025

Oct. 12, 2025

The offending font is NotoColorEmoji.ttf which is present in, e. g., google-noto-emoji-color-fonts or noto-fonts-emoji packages available in various distribution. Attempting to load this font on Windows 10 (with AddFontResourceA() or open it with default font viewer) fails while currently succeeds on Windows. fontforge also refuses to open this font. That is because the font is bitmap only but missing bitmap table. Some apps (Glyph launcher is an example) try to GetOutlineTextMetrics() on this font and do not expect that to have an error return (as we currenly do), which leads to crash on unhandled division by zero exception. I am attaching a bitmap-only ttf test font (with only one bitmap) which I created with fontforge to make sure that such font can still be loaded in Wine. This font also loads on Windows (both with AddFontResourceA() and with default font viewer). There are other font types which can be legitimately missing EBDT table, but FT_Load_Sfnt_Table() returns a different error for those and my patch doesn't reject those fonts. [test.ttf](/uploads/b41472180b80c2c53f9dcc06055990f0/test.ttf) -- v2: win32u: Don't load bitmap only TTF fonts without bitmap table. https://gitlab.winehq.org/wine/wine/-/merge_requests/411

3 2

[PATCH 0/5] MR9163: Cmd engine rewrite (part XXXVIII)
by eric pouech (＠epo) Oct. 12, 2025

Oct. 12, 2025

This MR starts implementing pipe between commands with: - parallelism between the two sides of the pipe - using real pipes. (Current code is sequential: running LHS, storing its output into a temp. file, then running RHS with temp. file as input). The "interesting" part is: - in order to achieve parallelism, native cmd.exe when LHS or RHS of pipe contains a builtin command or instruction, run this part in a new and separate cmd.exe instance. - which means that we need to transform back the parsed structure of a tree of instructions into a string for feeding the new cmd.exe instance ('rebuild'). This serie mainly: - adds some tests to cover some quirks in pipe handling (esp. when expansion occurs between parent and child process), - refactors some code for the next patches, - introduce a new node in parse tree to help in the rebuild process (will be shown in next serie, and will allow matching the generated trailing spaces), - implement the pipe mechanism for "simple" commands. Next serie will cover the non-"simple" commands. Notes: - the now successful tests in the last patch of this serie are achieved because now the command string in expanded twice (once in parent cmd.exeprocess, and the second time, in child process). - all the wine_todo introduced in this serie will be solved in next serie. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9163

2 5

[PATCH v3 0/3] MR9112: XCOPY and COPY should not attempt to copy a file to itself.
by Joe Souza (＠JoeS209) Oct. 11, 2025

Oct. 11, 2025

Current code attempts to copy a file to itself. File is not actually copied; instead, a file sharing error is received. This result is ugly and differs from native. Behavior now appears to be the same as native with changes in this MR . -- v3: cmd: Don't attempt to copy a file to itself. cmd/tests: Add tests for COPY to self. https://gitlab.winehq.org/wine/wine/-/merge_requests/9112

2 4

[PATCH 0/2] MR9161: dwrite: Update script information with Unicode 16.0 additions.
by Nikolay Sivov (＠nsivov) Oct. 11, 2025

Oct. 11, 2025

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9161

2 2

[PATCH 0/1] MR6140: ntdll: Exclude biggest envars to fit 32767 chars limit in get_initial_environment.
by Martino Fontana (＠tinozzo123) Oct. 11, 2025

Oct. 11, 2025

Windows has a limit of 32767 characters in the environment block. https://superuser.com/questions/1070272/why-does-windows-have-a-limit-on-en… Wine doesn't attempt to respect that at all. Do some programs actually depend on this? Unfortunately yes. With this patch, during initialization, if the block size would exceed (or be close to) the limit, the biggest environment variables will be excluded. This is useful when a user has very long environment variables in their system for reasons unrelated to Wine. Do note that there's still nothing done to make sure that the limit isn't exceeded after initialization. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56941 Signed-off-by: Martino Fontana <tinozzo123(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6140

7 12

[PATCH v2 0/2] MR9112: XCOPY and COPY should not attempt to copy a file to itself.
by Joe Souza (＠JoeS209) Oct. 11, 2025

Oct. 11, 2025

Current code attempts to copy a file to itself. File is not actually copied; instead, a file sharing error is received. This result is ugly and differs from native. Behavior now appears to be the same as native with changes in this MR . -- v2: cmd: Don't attempt to copy a file to itself. xcopy: Don't attempt to copy a file to itself. https://gitlab.winehq.org/wine/wine/-/merge_requests/9112

2 3