October 2023 - wine-gitlab

[PATCH v3 0/6] MR4092: user32: Actually implement RealGetWindowClass{A/W}.
by Connor McAdams (＠cmcadams) 17 Oct '23

17 Oct '23

-- v3: user32: Pass real argument to NtUserGetClassName in RealGetWindowClass{A/W}. win32u: Add support for retrieving real window class ID across processes. user32: Set real window class ID for user32 standard controls. win32u/tests: Add a test for real window class name retrieval. comctl32/tests: Add tests for RealGetWindowClass. user32/tests: Add tests for RealGetWindowClass. https://gitlab.winehq.org/wine/wine/-/merge_requests/4092

3 10

[PATCH v3 0/1] MR4107: wbemprox: Use correct string id.
by eric pouech (＠epo) 17 Oct '23

17 Oct '23

Don't use hard coded string indexes as one of the expected string can be absent, hence decreasing its index; nothing ensures that the strings are placed in the order of the fields in the smbios structure. So use, smbios structures' indexes instead. Wbemprox was also expecting one string too much. Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- v3: wbemprox: Use correct string id. https://gitlab.winehq.org/wine/wine/-/merge_requests/4107

3 3

Re: [PATCH v2 0/2] MR4108: Improve DMI tables under Linux.
by Hans Leidekker (＠hans) 17 Oct '23

17 Oct '23

On Tue Oct 17 13:58:32 2023 +0000, eric pouech wrote: > IMO there's no difference in privacy concerns between hardware ID and > software ones (some BIOS:es allow you to change the HW id, so the > boundary between HW or not is also not that clear). The point is what > they identify. > what are your concerns about following systemd recommandations? Like I said, Wine is not a regular application, it's just the middle layer between the Unix OS and Windows applications. Your proposal doesn't achieve systemd's goal because you can run multiple applications on Wine which would still get the same ID (even if run in different prefixes). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49001

1 0

Re: [PATCH v2 0/2] MR4108: Improve DMI tables under Linux.
by eric pouech (＠epo) 17 Oct '23

17 Oct '23

On Tue Oct 17 13:41:31 2023 +0000, Hans Leidekker wrote: > > concerning the migration phase: > > > > * do you have an idea of which applications make use of it? (asking in > case you have some idea, but likely we cannot be sure of all of it) > I remember working on a game but I forgot the name. Generally it's DRM > schemes that try to bind an account or install to a particular machine. > > * a countermeasure could be to set a flag in the Wine prefix > (dont_hash_machineid, at value 0 when not defined) to control the > activation of the hashing ; every new prefix would be created with the > flag set to 1 ; that would limit the impact, but not eradicate it (if > user reinstalls his/her app in newly created prefix) ; that could > eventually controlled in winecfg with more context on the pros&cons > I don't think we'd want such code in Wine. neither do I ;-) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_48999

1 0

Re: [PATCH v2 0/2] MR4108: Improve DMI tables under Linux.
by eric pouech (＠epo) 17 Oct '23

17 Oct '23

On Tue Oct 17 13:41:33 2023 +0000, Hans Leidekker wrote: > > for the very same reason that /sys/class/dmi/id/board_serial, > chassis_serial, product_serial and product_uuid are not readable by user > > > > exposing directly /etc/machine-id is hence a major privacy concern > > > > Note: Windows expose these HW id:s without constraints whereas Linux > puts some limitations. > Right, and macOS also exposes a hardware ID. Windows/Mac applications > should be equally careful with that information. I don't think exposing > /etc/machine-id is at the same level though. It's not a hardware ID and > you can change it. If privacy is a concern when running Windows > applications an alternative would be to sandbox Wine and give it its own > machine ID. IMO there's no difference in privacy concerns between hardware ID and software ones (some BIOS:es allow you to change the HW id, so the boundary between HW or not is also not that clear). The point is what they identify. what are your concerns about following systemd recommandations? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_48998

1 0

[PATCH 0/3] MR4127: dwrite: Clang warning fixes
by Jacek Caban (＠jacek) 17 Oct '23

17 Oct '23

This fixes -Wenum-conversion warnings (enabled by default on clang) and -Wpointer-sign warnings (enums are signed on MSVC target, so their pointers should not be implicitly converted to `unsigned int *`). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4127

3 5

Re: [PATCH v2 0/2] MR4108: Improve DMI tables under Linux.
by Hans Leidekker (＠hans) 17 Oct '23

17 Oct '23

> concerning the migration phase: > > * do you have an idea of which applications make use of it? (asking in case you have some idea, but likely we cannot be sure of all of it) I remember working on a game but I forgot the name. Generally it's DRM schemes that try to bind an account or install to a particular machine. > * a countermeasure could be to set a flag in the Wine prefix (dont_hash_machineid, at value 0 when not defined) to control the activation of the hashing ; every new prefix would be created with the flag set to 1 ; that would limit the impact, but not eradicate it (if user reinstalls his/her app in newly created prefix) ; that could eventually controlled in winecfg with more context on the pros&cons I don't think we'd want such code in Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_48993

1 0

Re: [PATCH v2 0/2] MR4108: Improve DMI tables under Linux.
by Hans Leidekker (＠hans) 17 Oct '23

17 Oct '23

> for the very same reason that /sys/class/dmi/id/board_serial, chassis_serial, product_serial and product_uuid are not readable by user > > exposing directly /etc/machine-id is hence a major privacy concern > > Note: Windows expose these HW id:s without constraints whereas Linux puts some limitations. Right, and macOS also exposes a hardware ID. Windows/Mac applications should be equally careful with that information. I don't think exposing /etc/machine-id is at the same level though. It's not a hardware ID and you can change it. If privacy is a concern when running Windows applications an alternative would be to sandbox Wine and give it its own machine ID. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_48991

1 0

[PATCH v9 0/7] MR401: Draft: vkd3d-shader/dxil: Read CBV info.
by Conor McCarthy (＠cmccarthy) 17 Oct '23

17 Oct '23

Goes atop MR 388 (the error codes would clash otherwise). The last four commits belong to this MR. -- v9: vkd3d-shader: Clone descriptor scan info from struct vkd3d_shader_desc. vkd3d-shader/dxil: Read CBV descriptors. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/401

3 9

[PATCH 0/2] MR4108: Improve DMI tables under Linux.
by eric pouech (＠epo) 17 Oct '23

17 Oct '23

This MR improves Wine's DMI tables by: - no longer exposing /etc/machine-id content. Current documentation of systemd strongly suggests to use a hash of it (with app dedicated key). (1) - generates DMI entries for files that are no longer user readable on Linux (like bios serial number). The values are derived from hashed value in step #1. (1) current implementation integrates into unix ntdll a bunch of sha 256 related code. It's basically a reimplementation of libsystemd's sd_id128_get_machine_app_specific(). We could alternatively dynamically link to libsystemd.so. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4108

3 6

2025

2024

2023

2022

wine-gitlab October 2023