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

[PATCH v5 0/4] MR8786: Draft: winebuild: Add flag to disable dynamicbase/aslr
by Tres Finocchiaro (＠tresf) Aug. 21, 2025

Aug. 21, 2025

Commit 518e394794160818ffe6826c874ff2f550c95bbb introduced new and important default behavior for PE binaries built using `winegcc`/`wineg++`/`winebuild`. * `/DYNAMICBASE` - Generates an executable image that can be randomly rebased at load time by using the address space layout randomization (ASLR) feature of Windows that was first available in Windows Vista. * `/HIGHENTROPYVA` - Randomized 64-bit virtual addresses make it more difficult for an attacker to guess the location of a particular memory region. ... however as identified in https://bugs.winehq.org/show_bug.cgi?id=58480, this new default behavior can severely impact applications that interact with binaries created for Windows XP and older. This is quite common for legacy audio plugins, such as VST2(TM) plugins. This MR keeps the new default "dynamicbase" and "highentropyva" flags by default, but mirrors the mingw/msys2 `--disable-dynamicbase` flag as explained here: https://www.msys2.org/news/#2021-01-31-aslr-enabled-by-default. MSVC also provides a similarly named flag [here](https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase). Downstream, the LMMS project has successfully deployed the mingw flag and the MSVC flag for our Windows builds. Our Linux builds use a custom wine-bridge and would benefit from the same. We've currently tested this MR downstream against a snapshot of master branch to passing results. Downstream PRs: * Linux: https://github.com/LMMS/lmms/pull/7987 * Windows: https://github.com/LMMS/lmms/pull/7976 -- v5: Fix typo https://gitlab.winehq.org/wine/wine/-/merge_requests/8786

3 5

Re: [PATCH v15 0/1] MR8778: sane.ds: Adding a window for loading and saving the scanner configuration
by Esme Povirk (＠madewokherd) Aug. 21, 2025

Aug. 21, 2025

On Thu Aug 21 12:49:58 2025 +0000, Ivan Lyugaev wrote: > Yes, I agree, my interface makes writing and reading the whole file, but > in the context of a small number of operations, I think it's acceptable. > I focused on making the configuration file readable for manual > modification (previously, I provided the writing format). An option was > to store the settings in a binary file and overwrite them based on the > offset provided by optno. > Would it be better to store all the settings in memory and save them to > a file once the scan starts or the window is closed? Using a human-readable format makes sense to me. I think you're right - as long as there aren't too many settings, the runtime cost is probably OK. > Would it be better to store all the settings in memory and save them to a file once the scan starts or the window is closed? I think this should be decided based on what users are most likely to expect (or want, as long as we can communicate it clearly). Personally, if there is a Cancel button, I expect clicking it, or manually closing the window, to discard any changes I've made (unless I've explicitly saved them somehow). One could change the Cancel button to Close, and then saving settings immediately might make more sense, but I'm not sure how many people would pick up on that. I would rather be able to Cancel, but that's just a personal preference. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8778#note_113527

1 0

Re: [PATCH v15 0/1] MR8778: sane.ds: Adding a window for loading and saving the scanner configuration
by Esme Povirk (＠madewokherd) Aug. 21, 2025

Aug. 21, 2025

On Thu Aug 21 19:17:04 2025 +0000, Ivan Lyugaev wrote: > This solution is based on previously defined values such as > ID_STATIC_BASE and etc. These values are also not used anywhere else, so > it is not rational to create a new file for them `CSIDL_LOCAL_APPDATA` is defined in `shlobj.h`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8778#note_113526

1 0

[PATCH 0/1] MR8802: win32u: Avoid calling server in NtUserGetKeyState() when input keystate is in sync.
by Paul Gofman (＠gofman) Aug. 21, 2025

Aug. 21, 2025

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

3 11

[PATCH v3 0/3] MR6878: dinput: Fix a couple of regressions.
by Paul Gofman (＠gofman) Aug. 21, 2025

Aug. 21, 2025

-- v3: dinput: Once again support creating joystick device with GUID_Joystick. dinput: Derive DIPROP_JOYSTICKID from device path enumeration. dinput/tests: Add tests for joystick id. https://gitlab.winehq.org/wine/wine/-/merge_requests/6878

2 3

[PATCH v3 0/2] MR8628: winepulse.drv: Synchronize audio streams with the same periods.
by Paul Gofman (＠gofman) Aug. 21, 2025

Aug. 21, 2025

-- v3: winepulse.drv: Process streams timer updates from PA main loop. winepulse.drv: Move pulse_release_stream() below. https://gitlab.winehq.org/wine/wine/-/merge_requests/8628

2 2

[PATCH v4 0/14] MR4406: Draft: win32u: Fix reported text extent and actual text size mismatch.
by Paul Gofman (＠gofman) Aug. 21, 2025

Aug. 21, 2025

Freetype's FT_Load_Glyph may return different glyph metrics (in particular, horiAdvance) depending on load target flags (FT_LOAD_TARGET_MONO, FT_LOAD_TARGET_NORMAL ...). Among the consequences of that are: - the size of, e. g, GetTextExtentPoint() doesn't match the size of actually rendered text; - DrawTextW() with DT_CALCRECT flag returns wrong bounding rectangle. In the core of that is GetGlyphOutline() returning different values for GGO_METRICS format (used in various glyph metrics query functions) and the actual format used during rendering. It probably make sense to use effective fonts rendering option for GGO_METRICS so that matches. I did some ad-hoc testing on Windows with currently problematic Tahoma font and quite expectedly GetGlyphOutline(GGO_METRICS) always returns the same metrics as other output format options. While all the options also have the same metrics between each other (which is still not the case with Wine). I guess it is not easily possible to make all the face load options match each other with freetype (nor I am sure that is always the case on Windows for all the possible fonts), but making GGO_METRICS return the metrics matching actual gdi device context setup looks more important. Fixes Idle Spiral being unable to render typed text in save / load dialogs (which is using Winforms from Unity's Mono). -- v4: fixup! win32u: Use font AA flags when querying glyph outline with GGO_METRICS. fixup! win32u: Use font AA flags when querying glyph outline with GGO_METRICS. (tmp, untested, helps ida) win32u: Don't force GGO_BITMAP for default bitmap in dibdrv_SelectFont(). Revert "winex11: Only request display modes driver data when needed." Revert "win32u: Read / write source modes as a single registry blob." Revert "win32u: Remove now unnecessary reset_display_manager_ctx." Revert "win32u: Use struct pci_id in struct gdi_gpu." Revert "win32u: Remove driver-specific id from struct gdi_gpu." Revert "win32u: Pass gdi_gpu structure members as add_gpu parameters." Revert "win32u: Return STATUS_ALREADY_COMPLETE from UpdateDisplayDevices." win32u: Use font AA flags when querying glyph outline with GGO_METRICS. d3dx9/tests: Make test_ID3DXFont() less dependent on GetGlyphOutlineW(GGO_METRICS) behaviour. win32u: Set all glyph load flags in get_load_flags(). win32u: Store effective AA flags in font_physdev. https://gitlab.winehq.org/wine/wine/-/merge_requests/4406

2 15

Re: [PATCH v15 0/1] MR8778: sane.ds: Adding a window for loading and saving the scanner configuration
by Ivan Lyugaev (＠valy) Aug. 21, 2025

Aug. 21, 2025

On Thu Aug 21 10:16:28 2025 +0000, Ivan Lyugaev wrote: > changed this line in version 7 of the diff I have changed the implementation of saving and loading based on your advice, and now I use GetSaveFileNameW and GetOpenFileNameW -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8778#note_113510

1 0

[PATCH v2 0/3] MR260: ntdll: Improve xstate validation in NtGetContextThread()
by Paul Gofman (＠gofman) Aug. 21, 2025

Aug. 21, 2025

Supposed to fix SCP: Secret Laboratory intermittent crash at main menu. The first two patches make the existing validation also work for other thread context query (as context_from_server called through get_thread_context() doesn't do that). The last patch adds xstate alignment validation with corresponding test. -- v2: ntdll: Validate xstate alignment in validate_context_xstate(). ntdll: Validate context xstate at once in NtGetContextThread(). ntdll: Factor out validate_context_xstate() function. https://gitlab.winehq.org/wine/wine/-/merge_requests/260

2 4

[PATCH v3 0/1] MR4914: ntdll: Avoid sending context in wait_suspend() when not required.
by Paul Gofman (＠gofman) Aug. 21, 2025

Aug. 21, 2025

Currently usr1_handler always delivers the context to server. With AVX enabled the single context size is around 1k (while there are two of those for wow64). I am now working on a more generic xstate support in contexts (mostly motivated by AVX512), with AVX512 the single context to be transferred to server is ~1k bigger. The context is needed to be passed to the server from usr1_handler only for NtGetContextThread, NtSetContextThread and NtSuspendThread handling (e. g., when stop_thread is called on the server). The vast majority of usr1_handler usage is for kernel APCs (e. g., APC_ASYNC_IO involved in every async operation) that don't need the thread context transferred to the server and back. My measurements of single SERVER_START_REQ( select ) in server_select() shows that the turnaround time of the request with the context (on native x64 without wow context) is almost two times bigger on average when currently supported AVX context is involved (that is, on every usr1_handle invocation on a machine supporting AVX). So, this patch is expected to increase the time of relatively rare calls which actually need contexts by roughly 50% but decrease the turnaround time of frequent calls involving system APCs by 50%. The difference will be more in favour of this patch once huge AVX512 contexts are added. -- v3: ntdll: Avoid sending context in wait_suspend() when not required. https://gitlab.winehq.org/wine/wine/-/merge_requests/4914

2 2