The Wrapped PST and Unicode Paths

  • Makale

A customer just raised this issue with our Wrapped PST provider sample. They were trying to retrofit the sample to use Unicode paths to the NST and found that the CreateStoreEntryID routine was producing an invalid entry ID after they changed to to use a Unicode path. Through experimentation, they were able to produce a valid entry ID and wondered if I could document the necessary format. It turns out we use two different formats for the entry ID of a wrapped PST. One format is for ASCII paths and the other is for Unicode paths. Here they are, represented as structures:

 typedef struct             // short format

 {

  BYTE        rgbFlags[4];    // MAPI-defined flags

  MAPIUID     uid;        // PST provider MUID

  BYTE        bReserved;  // Reserved (must be zero)

  CHAR        szPath[1];  // Full path to store (ASCII)

 } EIDMS;

 

 // Unicode version of EIDMSW is an extension of EIDMS

 // and szPath is always NULL

 typedef struct             // Long format to support Unicode path and name

 {

  BYTE        rgbFlags[4];    // MAPI-defined flags

  MAPIUID     uid;        // PST provider MUID

  BYTE        bReserved;  // Reserved (must be zero)

  CHAR        szPath[1];  // ASCII path to store is always NULL

  WCHAR       wzPath[1];  // Full path to store (Unicode)

 } EIDMSW;

The net effect of the difference in these structures is there are two NULL bytes prior to a Unicode path. If you’re interpreting the entry ID, one way to determine how to interpret it would be to cast it as EIDMS first, then check if szPath[0] is NULL. If it is, you need to cast it as EIDMSW instead.

Comments

  • Anonymous
    August 06, 2012
    PR_PROFILE_OFFLINE_STORE_PATH and PST_PST_PATH are still defined as being PT_STRING8.  Is it only the store entry ID that can contain a UTF-16 path?

  • Anonymous
    August 07, 2012
    Cain, you can define the PST_PATH_W and PR_PROFILE_OFFLINE_STORE_PATH_W just by using PT_UNICODE PROP_TAG macro - mapi will happily take it.  Separate problem that you'll encounter would be path to the store-provider dll ( assuming you want to put it in your custom dir ).  That one is translated utf-16->mbcs using local codepage with all the drawbacks...