On Thu Mar 19 12:49:07 2026 +0000, Connor McAdams wrote:
From [rfc4122](https://www.ietf.org/rfc/rfc4122.txt): ``` 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time_low | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time_mid | time_hi_and_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |clk_seq_hi_res | clk_seq_low | node (0-1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | node (2-5) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` For UUID version 1: ``` o Set the clock_seq_low field to the eight least significant bits (bits zero through 7) of the clock sequence in the same order of significance. o Set the 6 least significant bits (bits zero through 5) of the clock_seq_hi_and_reserved field to the 6 most significant bits (bits 8 through 13) of the clock sequence in the same order of significance. ``` So I think that part of `UuidCreateSequential()`'s implementation is incorrect. I didn't know that `UuidCreateSequential` created version 1 UUIDs, however it has some differences with how dinput generates its `guidInstance` values. It sets the `node` fields to the MAC address of the computer, whereas dinput sets the node field to all 0s and an ASCII `DEST` as the final bytes. It also does not increment the clock sequence value each time a new UUID is created. I could imagine a scenario where the node portion of the ID being different might trip a game up, but I have no concrete evidence for it. If all that matters is that a unique ID is created, we can use `UuidCreateSequential()` if that's what you'd prefer. Okay, I was thinking that the tail bytes could be set later but other differences make it sound reasonable to duplicate the implementation.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10364#note_132777