A GUID getter for assembly language

[NoCforMe]

We were discussing GUIDs in another thread. I took a look at the little Microsoft utility to get GUIDs, GUIDGEN.EXE. After figuring out how to get a GUID (easy peasy, just call UuidCreate()), I thought it might be nice to have a utility like that more useful to us assembly-language programmers.

Here it is, attached to this post. It displays the GUID in three forms: as the standard XXXXXXXX-XXXX-XXXX ... form, as a set of DB statements, and as a GUID structure declaration.

It works fine. However, before anyone starts using this, I wonder if someone could check my work here. Specifically, I'm really not sure about byte (and nybble) order. The top display field shows the data returned in the GUID structure as a sequence of bytes, left to right. What I'm not sure about is the values in the GUID structure (last field). Are those values correct? They're both byte- and nybble-swapped. (Dontcha just love little-endianness?)

So where the first part (4 bytes, 8 hex characters) is FCFFD8CD, the DWORD value in the structure is 0DC8DFFCFh. Izzat correct?

[sinsi]

Just use UuidToString to see how the bytes are formatted.

edit: The program works OK

[TimoVJL]

Also a string for register would be useful, as it might be needed for later usage.

[NoCforMe]

Also a string for register would be useful, as it might be needed for later usage.

You mean for the registry? I thought that was the XXXXXXXX-XXXX-XXXX ... form. What format exactly is it?

[NoCforMe]

edit: The program works OK

Welllll ... there was a pretty basic error in there (I left out a character from my hex conversion table). Fixed that, but I'm still very confused. Check out screen shot:



The output from UuidToString() is shown in the status bar at bottom, so we can assume that's correct, right? So what's the correct byte order for things? I guess my GUID string (1st one at top) should match that one, right? Which means they're using the binary order (little-endian), not the byte order. Aaaaargh.

[sinsi]

The output from UuidToString() is shown in the status bar at bottom

Not here.

[NoCforMe]

Sorry, a later revision. See screenshot. Well, might as well attach it here.

[sinsi]

Here's what I get

Code Select Expand

e4 4c 54 8a 70 77 18 4d-83 70 0a e4 8a 29 78 52
8a544ce4-7770-4d18-8370-0ae48a297852
Typical MS, the format doesn't match the structure layout.

[NoCforMe]

So it looks like my mistake was reversing nybbles within each byte.

In your example, it looks like it does match the structure. First 4 bytes:

Code Select Expand

e4 4c 54 8a
which makes a DWORD (Data1) of

Code Select Expand

8a544ce4
Right?

[sinsi]

Code Select Expand

GUID STRUCT
 Data1 DWORD ?
 Data2 WORD  ?
 Data3 WORD  ?
 Data4 BYTE  8 DUP (?)
GUID ENDS
Doesn't match the grouping
 Data1 dd 8a544ce4h
 Data2 dw 7770h
 Data3 dw 4d18h
 Data? db 83h,70h
 Data? db 0ah,0e4h,8ah,29h,78h,52h
[/code]

[NoCforMe]

Wonder if there's a good (and accurate) description of the actual layout somewhere online?
(Besides the Micro$oft docs!)

[C3]

Wonder if there's a good (and accurate) description of the actual layout somewhere online?

Sinsi's structure is ok. Windows Learn: https://learn.microsoft.com/en-us/windows/win32/api/guiddef/ns-guiddef-guid

[NoCforMe]

Yes, we know the structure is correct. But what about the byte order of the data? That's the issue here.

[sinsi]

If you look at the layout, it's xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 8-4-4-4-12 digits
but the structure is 8-4-4-16, and the last 8 bytes (4-12 16 digits) are split but in a weird way.

[NoCforMe]

How about this: let's take a completely empirical approach:

• Use UuidCreate() to get a GUID
• Look at the data in the GUID structure, byte by byte
• Use UuidToString() to create the string
• Compare the data layout to the byte order in the string

That should show us the correct order of things.