FGetComponentPath and Unicode

From Austria came the report that the Unicode build of MFCMAPI wasn’t working right for non-English builds of Outlook. They had already debugged and narrowed the problem down to FGetComponentPath not working, even though it worked in the non-Unicode build of MFCMAPI. This was bizarre, since all the parameters should be the same in both builds, having been obtained from the registry, and there’s no flag passed to FGetComponentPath to indicate we’re in a Unicode build. So – how could we call the same function, on the same system, with the exact same parameters, and get different results?

I looked at what was different between the two scenarios. In the ANSI build of MFCMAPI, we request these strings using RegQueryValueExA, then pass the strings directly to FGetComponentPath. In the Unicode build, since FGetComponentPath only takes ANSI strings, after we request the strings using RegQueryValueExW, we convert the results from Unicode to ANSI using WideCharToMultiByte. I confirmed in the debugger that the strings in both cases were the same, yet we still got different results!

So I debugged FGetComponentPath itself and found, to my surprise, that the strings were indeed different. In the ANSI case, after the NULL terminator was another string, and FGetComponentPath was reading this string. In the Unicode build, we lose this extra data during our conversion because we stop at the NULL terminator!

The registry keys in question here are MSIComponentID, MSIApplicationLCID, and MSIOfficeLCID, which I last talked about here. When we look at them in the registry, we can see the problem – MSIApplicationLCID and MSIOfficeLCID are not REG_SZ after all. Instead, they are REG_MULTI_SZ, so these internal NULLs separating the strings are actually expected.

The fix here was to just make sure any reg keys I read for FGetComponentPath’s consumption were read using RegQueryValueExA. Then I don’t have to deal with converting the data, and FGetComponentPath gets everything in the format it expects. This fix will be in the next build of MFCMAPI.