This pretty much demonstrates another reason to Use Unicode, but if you do need to use some non-Unicode encoding until you can convert to Unicode, please don't use these flags.
MultiByteToWideChar() and WideCharToMultiByte() provide some interesting sounding flags that are actually useless, slow, badly broken, or far worse. All of these flags would be expected to behave like Unicode Normalization, so you should instead use NormalizeString() to handle the desired behavior, either Form C for composed strings or Form D for decomposed strings.
MB_PRECOMPOSED is the simplest to address: Basically this flag doesn't really do anything. Nominally it would put data into something like Normalization Form C, however most code pages are already in a composed form, so there's little real impact. Just to make sure, the flag's ignored internally :)
MB_COMPOSITE is my most hated of these flags. First of all, it nominally pretends to put the data into something like Normalization Form D, decomposed into a base character and combining characters. To me that's the opposite of "Composite". Indeed, I've seen numerous code examples that seem to be passing MB_COMPOSITE expecting Form C data, and pretty much zero examples expecting Form D data. Windows leans towards Form C internally (though you may use Form D or mixed data), so this flag probably isn't that helpful. If you really want to decompose your data, then use NormalizeString with Form D instead of this flag.
MB_COMPOSITE also is very slow because it does a lookup in some data tables. NormalizeString with Form D is probably faster.
MB_COMPOSITE also has some horrible behavior for many code points:
WC_COMPOSITECHECK basically has all of the problems of MB_COMPOSITE (its used in the other direction). Its name isn't as annoying to me though. Nominally WC_COMPOSITECHECK puts the data into Normalization Form C before encoding. Since most code pages are in a composed form Normalization Form C isn't a bad idea, however please use NormalizeString with Form C instead of this flag.
WC_COMPOSITECHECK is also very slow because of the way it does lookup. NormalizeString with Form C is probably faster.
WC_COMPOSITECHECK also has horrible behavior for many code points:
Hopefully I've terrified you and you'll stop using these flags, perhaps using NormalizeString() if you really need similar behavior. Most applications don't even really need that though. Of course you always have the option of Using Unicode!
'til next time,Shawn