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