Guid Byte Order in .NET

It appears that MS are storing the five parts in a structure.
The first 4 parts are either 2 or 4 bytes long and are therefore probably stored as a native type (ie. WORD and DWORD) in little endian format. The last part is 6 bytes long and it therefore handled differently (probably an array).

Does the Spec state that the GUID is stored in big-endian order, or that the storage of parts are in that order but the indiviual parts may be implementation specific?

EDIT:

From the UUID spec, section 4.1.2. Layout and Byte Order (emphasis mine):

To minimize confusion about bit assignments within octets, the UUID
record definition is defined only in terms of fields that are
integral numbers of octets. The fields are presented with the most
significant one first.

In the absence of explicit application or presentation protocol
specification to the contrary
, a UUID is encoded as a 128-bit object,
as follows:

The fields are encoded as 16 octets, with the sizes and order of
the fields defined above, and with each field encoded with the Most
Significant Byte first (known as network byte order).

It might be that MS have stored the bytes in the correct order, but have not bothered to network-to-host order the WORD and DWORD parts for presentation (which appears to be ok according to the spec, at least by my unskilled reading of it.)

Leave a Comment