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; // MAPI-defined flags
MAPIUID uid; // PST provider MUID
BYTE bReserved; // Reserved (must be zero)
CHAR szPath; // Full path to store (ASCII)
// Unicode version of EIDMSW is an extension of EIDMS
// and szPath is always NULL
typedef struct // Long format to support Unicode path and name
CHAR szPath; // ASCII path to store is always NULL
WCHAR wzPath; // Full path to store (Unicode)
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 is NULL. If it is, you need to cast it as EIDMSW instead.
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?
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...