The Wrapped PST and Unicode Paths

A customer just raised this issue with out 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.