What's the difference between UuidFromString, IIDFromString, CLSIDFromString, GUIDFromString...

A GUID and a CLSID and an IID are all the same as a UUID, but there are separate functions for converting a string into a GUID, CLSID, IID, and UUID. Are they all equivalent? If not, what's the difference? And which one should I use?

The basic form for a UUID string is xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx where each x is a hexadecimal digit, case-insensitive. (I personally prefer all-uppercase.) All of the parsing functions under discussion use this basic form as their basis of exploration. Some functions expect the basic form to be enclosed in curly braces; others do not.

Let's start with Uuid­From­String. It takes a string in basic form without curly braces. As a special case, if you pass NULL instead of a valid string pointer, the function still succeeds and sets the result to GUID_NULL.

Next up is IID­From­String. This function takes a string in basic form with curly braces. It also has the behavior that passing NULL as the string results in success and GUID_NULL.

Slightly more complicated is CLSID­From­String. In addition to accepting a brace-enclosed string (which is treated as a GUID), it also accepts a ProgId. In the ProgId case, it returns the CLSID associated with that ProgId. For example, if you ask for Paint.Picture, it will return the GUID {D3E34B21-9D75-101A-8C3D-00AA001A1652}. As with the other functions, passing NULL is valid and results in GUID_NULL.

Last is GUID­From­String. This function is one of those "Not guaranteed to be supported beyond Windows Vista" functions, so you should probably steer clear. (Another clue that calling it is probably a bad idea: The function is not exposed in any header file or import library.) But if you insist: It accepts a brace-enclosed string, and NULL is not allowed. Furthermore, it ignores any garbage after the trailing brace. This function was not intended for public consumption, so these strange quirks are not entirely unexpected.

Let's summarize in a table, since that seems to be popular. I added a final column describing whether the function available in A/W variants or is Unicode-only.