Some times I wondered why SV’s definition for GUIDs is structured as a group like this:
GUID group, type Data1 long Data2 short Data3 short Data4 byte, dim(8) end
instead of something more straightforward, like guid STRING('<011h,022h,033h....>').
While troubleshooting a problem with an API call that expects a GUID constant, I found the answer in Wikipedia’s article on Universally unique identifier:
An exception to this are Microsoft’s variant 2 UUIDs (“GUID”): historically used in COM/OLE libraries, they use a little-endian format, but appear mixed-endian with the first three components of the UUID as little-endian and last two big-endian. Microsoft’s GUID structure defines the last eight bytes as an 8-byte array, which are serialized in ascending order, which makes the byte representation appear mixed-endian.[23] For example, 00112233-4455-6677-8899-aabbccddeeff is encoded as the bytes 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff .
Understanding this, a GUID constant can declared in the data section like this:
PROGRAM !00112233-4455-6677-8899-aabbccddeeff GuidA GROUP Data1 LONG(000112233h) Data2 SHORT(04455h) Data3 SHORT(06677h) Data4Str STRING('<088h,099h,0AAh,0BBh,0CCh,0DDh,0EEh,0FFh>') !There is no need for a byte array END !33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff Expected STRING('<033h,022h,011h,000h,055h,044h,077h,066h,088h,099h,0AAh,0BBh,0CCh,0DDh,0EEh,0FFh>') CODE PRAGMA('define(asserts=>on)') ASSERT(GuidA = Expected)
