> 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
> 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
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
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
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v5: programs/vkd3d-compiler: Dynamically allocate options array.
vkd3d-shader/tpf: Convert some of the semantic names to system values names when in compatibility mode.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/381
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v16: vkd3d-shader/tpf: Write out 'switch' statements.
vkd3d-shader/hlsl: Add a pass to validate switch cases blocks.
vkd3d-shader/hlsl: Add a pass to remove unreachable code.
vkd3d-shader/hlsl: Add copy propagation logic for switches.
vkd3d-shader/hlsl: Validate break/continue context.
vkd3d-shader/hlsl: Check for duplicate case statements.
vkd3d-shader/hlsl: Add initial support for parsing 'switch' statements.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/361
Full focus lost / focus gained events on the Windows side are not
feasible for X11's FocusIn/FocusOut events generated by keyboard grabs
(see XGrabKeyboard()) that are used for example for Atl+Tab handling.
Using them would degrade user's experience by causing the window to
minimize or flash multiple times depending on a game/window manager
combo.
Because of that the programs may miss on some KEYUP events that happen
during the grab, and since there are no focus changes on the Windows
side the state doesn't get resynced.
This change attempts to improve user experience by syncing any missed
key release events that happened while the window haven't had focus on
the X11 side.
There's no syncing of key presses as those are more problematic because
of window manager quirks, e.g. on KDE it may end up syncing the Tab
press portion of Alt+Tab. Luckily missing key events for keys that were
pressed and not released while the WM had the keyboard grab is not
nearly as confusing as stuck keys.
For Warhammer: Chaosbane, theHunter: Call of the Wild, Far Cry Primal
and many other games that end up with stuck Alt after Alt+Tabbing.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4126
Hans Leidekker (@hans) commented about dlls/wbemprox/builtin.c:
> rec->manufacturer = get_bios_manufacturer( buf, len );
> rec->name = L"Default System BIOS";
> rec->releasedate = get_bios_releasedate( buf, len );
> - rec->serialnumber = get_bios_serialnumber( buf, len );
> + rec->serialnumber = L"Serial number";
You also need to remove COL_FLAG_DYNAMIC from the column definition otherwise free() will be called on a static string.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4107#note_48966