Open thinlaunch opened 6 years ago
It appears the first (3) fields are encoded in little-endian for SMBIOS Ver >=2.6. Here is the info from the document and a suggested order:
Although RFC4122 recommends network byte order for all fields, the PC industry (including the ACPI, UEFI, and Microsoft specifications) has consistently used little-endian byte encoding for the first three fields: time_low, time_mid, time_hi_and_version. The same encoding, also known as wire format, should also be used for the SMBIOS representation of the UUID. The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented as: 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF. If the value is all FFh, the ID is not currently present in the system, but it can be set. If the value is all 00h, the ID is not present in the system.
The array order would be: first 8 bytes: p[3], p[2], p[1], p[0], p[5], p[4], p[7], p[6], last 8 bytes:p[8], p[9], p[10], p[11], p[12], p[13], p[14], p[15]
I will work on a patch for the PAS file.
I will work on a patch for the PAS file.
Still WIP?
If I issue wmic csproduct get uuid (WMI get SMBIOS UUID) it returns the following string: 81462904-7B5D-E111-ADCD-2C27D725B21D
Delphi uSMBIOS returns: 042946815D7B11E1ADCD2C27D725B21D
The last 16 bytes are always the same but the first 16 and different.
For example: 814629047B5DE111-ADCD2C27D725B21D 042946815D7B11E1-ADCD2C27D725B21D
Can you please assist? Is this a bug?