Problem with definition of GUID

Aug 12, 2011 at 8:32 PM
Edited Aug 12, 2011 at 8:33 PM

The GUID definition has two minor issues. It is defined as

ulong data1;
short data2;
short data3;
byte data4[8];

The smaller problem is that this differs from the way GUIDs are usually shown, which is {12345678-1234-1234-1234-1234567890ab}. To match standard display practice, there should be a short data4, followed by a 6-byte data5. I have found that letting data4[0] replace the first byte of the leading word, data4[1] the second byte, works, so the representation of the above value as an initializer would be {0x12345678, 0x1234, 0x1234, {0x12, 0x34, 0x12, 0x34, 0x56, 0x78, 0x90, 0xab}};

Note the order of data4[0] and data4[1] are the reverse of what you might expect.

The second problem lies in the definition of data2 and data3 as short. The initializers

pstsdk::guid PSETID_Messaging = {0x41F28F13, 0x83F4, 0x4114, {0xA5, 0x84, 0xEE, 0xDB, 0x5A, 0x6B, 0x0B, 0xFF}};
pstsdk::guid PSETID_UnifiedMessaging = {0x4442858E, 0xA9E3, 0x4E80, {0xB9, 0x00, 0x31, 0x7A, 0x21, 0x0C, 0xC1, 0x5B}};

fail with "warning 4309: truncation of constant value" because the data2 values for each of them are greater than MAX_SHORT. I believe that these should be defined as ushort rather than short.

Aug 16, 2011 at 8:55 PM

That GUID definition matches (or is suppose to match) the definition in the windows SDK, which is why it's broken up like it is. That being said, you are right: they should be unsigned shorts. I'll make a note of it.