- Wine-GitLab - list.winehq.org

[PATCH v2 0/1] MR8134: Draft: d3d10/tests: Compile more test effects from sources.
by Nikolay Sivov (＠nsivov) Aug. 21, 2025

Aug. 21, 2025

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: d3d10/tests: Compile more test effects from sources. https://gitlab.winehq.org/wine/wine/-/merge_requests/8134

2 1

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 20:40:08 2025 +0000, Esme Povirk wrote: > That would be much simpler. I'm guessing this wasn't done so that > alternative configurations could be stored in a separate file. Alternative configurations could be stored in named keys in the registry though. This might be an easier UI, since you could select them with a combo box. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8778#note_113532

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 20:05:30 2025 +0000, Alexandre Julliard wrote: > I'd suggest to store settings in the registry instead. That would be much simpler. I'm guessing this wasn't done so that alternative configurations could be stored in a separate file. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8778#note_113531

1 0

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

Aug. 21, 2025

On Thu Aug 21 19:55:55 2025 +0000, Esme Povirk wrote: > 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. I'd suggest to store settings in the registry instead. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8778#note_113530

1 0

[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