by Michael S. Kaplan, published on 2010/07/25 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/07/25/10028168.aspx
Over in the Suggestion Box, Pete asked:
I've been reading what you have to say about the deep, insatiable depravity that is CP_THREAD_ACP, and I can't say I disagree. My goal when writing Win32 string code is to start in UTF-16 and stay there as long as possible, and, when I can't start there, get there as soon as possible. Sadly, though, one must sometimes mediate between good and evil, such as when one writes a general-purpose library which needs to call an API which not only lacks a W variant but also seems to think code pages make perfect sense to everyone on all systems at all times, so doesn't bother to mention its needs or expectations. An example would be FGetComponentPath, but I think there are some cases in the old Outlook Express API as well. In these sorts of cases, we might benefit from your guidance on which to use, CP_ACP or CP_THREAD_ACP. Can one even generalize? And, if not, how might one determine the correct constant for each case?
I think Pete was referring to blogs like Nothing stinks worse than the thread locale, other than the thread code page, where I am so subtle about my feelings for some constructs that one might miss the subtext....
But for the general scenario here, the question of what code page to use?
There is no "always correct" answer.
I mean for FGetComponentPath there is a simple answer, which is use CP_ACP. Since that is what it is going to use.
And if the private mapi32.dll stub is to be shoved in a directory that contains off-CP_ACP or Unicode-only characters, you are basically screwed trying to do this in some cases (like if short file name generation is turned off).
Okay, I guess there is an answer here of a sort, after all.
You have to match the code page of whatever function you are calling!
Usually that will be CP_ACP but there are hundreds of exceptions out there (many of which I have written about in the past), and sometimes the only way exceptions are found is to use CP_ACP and notice the bug caused thereby. If MSLU taught me anything is that nobody bothered to document most of this stuff (beyond my occasional efforts, of course!).
Generally speaking, there are better answers in most cases, even with functions like FGetComponentPath, depending on what you are trying to do with the function.
As a by-the-way, the docs for FGetComponentPath are confusing anyway (they are all [in]parameters? Really? That would be more of an FSetComponentPath if it were true!)....