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.
I somehow missed when we posted this (here is Paul’s announcement), but the PST File Format Specification has been published. This should be everything you need to know to write parsers capable of reading and writing PST files without involving any pesky MAPI providers. Enjoy!
Angela posted an overview of the Outlook Social Connector yesterday. In addition to LinkedIn, Facebook, and Myspace providers, you’ll also be able to write your own. And the best part, which I don’t think we’ve announced before, is that we’ll be shipping the OSC as an add-in for Outlook 2007 and 2003, so you can get all that social goodness even if you’re not yet on Outlook 2010!
My team will be providing support for developers writing these providers. We’re very much looking forward to supporting this new platform.