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
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
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
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
--
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
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
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
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