October 2023 - Wine-GitLab - list.winehq.org

[PATCH 0/1] MR410: tests: Specify argument types for dxcompiler_create().
by Henri Verbeet (＠hverbeet) Oct. 17, 2023

Oct. 17, 2023

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/410

4 4

[PATCH v6 0/3] MR388: vkd3d-shader/dxil: Read some shader properties.
by Conor McCarthy (＠cmccarthy) Oct. 17, 2023

Oct. 17, 2023

-- v6: vkd3d-shader/dxil: Read DXIL compute shader thread group dimensions. vkd3d-shader/dxil: Read DXIL global flags. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/388

3 4

[PATCH v2 0/10] MR413: Draft: ci: Run the crosstests on Windows.
by Giovanni Mascellani (＠giomasce) Oct. 17, 2023

Oct. 17, 2023

This depends on !412, and might need some finishing touches before being ready. -- v2: ci: Run the HLSL compiler tests on Windows. ci: Run the HLSL preprocessor tests on Windows. ci: Run cross tests on Windows. tests: Skip processing resources according to [require] directives. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/413

3 11

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

Oct. 17, 2023

-- 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) Oct. 17, 2023

Oct. 17, 2023

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) Oct. 17, 2023

Oct. 17, 2023

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) Oct. 17, 2023

Oct. 17, 2023

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) Oct. 17, 2023

Oct. 17, 2023

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) Oct. 17, 2023

Oct. 17, 2023

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) Oct. 17, 2023

Oct. 17, 2023

> 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