News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

A GUID getter for assembly language

Started by NoCforMe, June 30, 2024, 04:45:17 PM

Previous topic - Next topic

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?


Assembly language programming should be fun. That's why I do it.

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.
May the source be with you

NoCforMe

Quote from: TimoVJL on June 30, 2024, 06:22:38 PMAlso 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?
Assembly language programming should be fun. That's why I do it.

NoCforMe

Quote from: sinsi on June 30, 2024, 05:25:17 PMedit: 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.
Assembly language programming should be fun. That's why I do it.

sinsi

Quote from: NoCforMe on June 30, 2024, 07:03:37 PMThe 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.
Assembly language programming should be fun. That's why I do it.

sinsi

Here's what I get
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:
e4 4c 54 8a
which makes a DWORD (Data1) of
8a544ce4
Right?
Assembly language programming should be fun. That's why I do it.

sinsi

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!)
Assembly language programming should be fun. That's why I do it.

C3

Quote from: NoCforMe on June 30, 2024, 08:26:47 PMWonder 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.
Assembly language programming should be fun. That's why I do it.

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.
Assembly language programming should be fun. That's why I do it.