https://bugs.winehq.org/show_bug.cgi?id=49160
--- Comment #1 from Hans Leidekker hans@meelstraat.net --- (In reply to Jamieson Christian from comment #0)
Line 1103: Baseboard serial number = L"None"
This is a fallback value. On Linux these values are read from files in /sys/class/dmi/id/* but in this case /sys/class/dmi/id/board_serial is readable only by root, hence the fallback. Note that virtual machines like Qemu and VirtualBox also don't provide this value under Windows.
Line 1295: BIOS serial number = L"0"
Linux doesn't export this value at all. I also don't see it on Windows running on Qemu or VirtualBox. Windows on real hardware returns "System Serial Number" here.
Line 2117: DiskDrive serial number = L"WINEHDISK"
Looks like we can do better here. It should be possible to retrieve the disk serial number through dbus, or we could perhaps substitute the volume serial number.
Line 3216: Processor unique ID = NULL
This isn't available even on Windows on modern hardware.
Line 3417: OS serial number = L"12345-OEM-1234567-12345"
We should read this from HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProductId. While this is currently also set to a fixed value it would at least give users the opportunity to change the value. I guess we could improve on this by generating a unique value on prefix creation.
As a consequence of the above, the value of Unity's SystemInfo.deviceUniqueIdentifier is always:
12a9126b14ff9b78b28d00f78e2bff20a224611b
PROPOSED:
If it is impractical to obtain actual serial numbers/IDs for the aforementioned components, consider populating the values in a way that facilitates more convenient user customization to workaround application issues.
- Consider sourcing the values from specially designated registry keys,
populated during new WINE_PREFIX setup.
- Consider populating said registry keys with random values rather than
fixed values. This will obviate the need for users to do any manual workarounds. (Not sure if it would break other things, but philosophically, it's not unreasonable to treat every WINE_PREFIX as though it's a whole new system build.)
I don't think we want to introduce registry values that don't exist on Windows for this purpose.