Share via

MAPI Store Providers and Outlook 2003

  • Article

Put this together from a posting I made to the MAPI-L list and a couple cases I worked recently:

The problem is with MAPI store providers that just don't work when loaded under Outlook 2003. The developers of the providers, when they contact us, are usually convinced the problem is a bug in Outlook 2003 since the providers “worked perfectly” under Outlook XP. My experience though, is that the problem is that Outlook 2003 demands so much more of the MAPI spec than previous versions of Outlook that bugs which have always been in these providers are now exposed. What's very interesting though is that I'm seeing the same bugs over and over in these providers. I hope to highlight the source of these bugs and offer some ideas on how to correct them.

There is a book which is very much coveted in the MAPI development community: Inside MAPI. One of the samples in this book is MSLMS, the Microsoft Sample Local Message Store. For what it is, sample code demonstrating how to write a message store provider, it's great. I'm not aware of any other sample message store out there. So it does not suprise me that a number of people choose to base their provider on the code in MSLMS. As such, they tend to inherit the same bugs and design flaws present in the sample.

I recently spent a couple days hacking on the MSLMS sample so that it could load under Outlook 2003. Here's a short list of the problems I found and what I had to do to fix them:

  • Two heaps we're being allocated for the Provider object, then used in all objects - the heaps were destroyed when the Provider object was destroyed, meaning we'd crash if any object had a longer lifetime. Fixed this by introducing DLLMain and creating/destroying the heaps on module load and unload. Putting this code in DLLMain may not be safe, but it stopped the crash for now. In production code, I'd find a better solution.
  • PR_RECORD_KEY abuse: This bug will stop a provider cold in Outlook 2003.In a number of tables, PR_RECORD_KEY for all objects was
    returning the store's record key instead of the key associated with the individual objects. Since Outlook 2003 depends on PR_RECORD_KEY to cache objects, this error effectively meant nothing in the provider could be rendered. The fix is to make sure PR_RECORD_KEY is unique for all objects and can be accessed through the object and contents tables and hierarchy tables.
  • GetNamesFromIDs deviated far from the MAPI spec. Suppose we make this call asking for two IDs, one which does exist and one which doesn't. MSLMS would return an array with one result, leaving the caller with no way to determine which ID got matched to a name. The correct thing to do is return an array with two entries - one being the matched name and the other indicating an error.
  • Multivalued string and multivalued binary props - The code which handled property persistance failed both of these cases. These properties can get quite complex, with a number of internal pointers. From what I could tell, it did attempt to address them, but it failed to fix up all of the internal pointers when flattening the data structures on save and unflattening them on load. In addition to failing to persist data, this bug also lead to a number of crashes due to the invalid pointers.
  • Named properties were being excluded from contents tables: Don't know why they were being blocked, but this meant Outlook couldn't get to some data on items that it expected to be able to retrieve through the contents table.

Those are just the problems I fixed. Here are some I didn't:

  • PR_RECORD_KEY (again): MSLMS assumes it can always use PR_ENTRY_ID when asked for PR_RECORD_KEY. This assumption breaks down on attachments, where objects do have PR_RECORD_KEY, but do not have PR_ENTRY_ID.
  • MV_INSTANCE: This somewhat obscure flag is at the heart of Outlook's code for handling the Group By box. MSLMS doesn't support the flag. Another effect is that Contact Address books cannot be hosted in MSLMS because the contab32 address book provider depends on the underlying store provider having support for this flag.

Anyone who has based their message store provider on MSLMS (even if it was “What would MSLMS do?“ and not just borrowing the code) needs to review their code and ensure they've addressed all of the above bugs before they approve their provider for support under Outlook 2003.

Comments

  • Anonymous
    July 08, 2004
    Its good to see blogs on MAPI stuff as its pretty difficult to get any details on the internals of MAPI.

  • Anonymous
    May 16, 2005
    Anyone out there got any idea where I can get a sample Message Store provider ? The only one I know of is "Inside MAPI". Can MS supply one ?

  • Anonymous
    June 13, 2005
    Stephen,

    Thank you for taking the time to update this blog. I am a newbie and the whole blog thing. I have a VERY simple Message Store Provider sample that I would like to share. I tried using MSLMS but got too frustrated with all the bugs. Even the sample code that comes with Inside MAPI states that their sample is not finished. What's up with that? Your sample was VERY helpful. I reomoved the whole Back End Database architecture to simplify the design and it looks great. I am stuck on a problem where Outlook XP seems to call CMSPLogon::Logoff just after getting the Entry IDS for the main folders (IPM Subtree, Trash, etc.) for no apparent reason. This causes some internal problems. I tracked it to MSMAPI32.DLL however I cannot seem to find a debug version of this DLL. Do you know where I might be able to locate debug versions of MAPI32.DLL and MSMAPI32.DLL?

    Thank you.

  • Anonymous
    June 27, 2005
    hello David,

    I was wondering if your could share your Store provider with me. I am trying to create a local pst store which will be read onlt in nature...

    Thanks ,
    Bikash

  • Anonymous
    August 08, 2005
    A while back, I posted an article about the fixes Jason and I had to make to the MSLMS sample...

  • Anonymous
    September 22, 2005
    The link for the updated MSLMS sample is no longer valid. Does anyone have an updated link or copy available? http://stephen_griffin.members.winisp.net/mslms/mslms.zip

  • Anonymous
    September 27, 2005
    I just tried it and it's working for me. Perhaps winisp was temporarily down...

  • Anonymous
    October 27, 2005
    I'm having problems installing mslms sample and smpms sample (microsoft's sample from MSDN) on outlook 2003. I do not see any new service listed when I add a new "account" and choose "Additional server types". Here is what I did - Maybe I missed something ? I compiled both DLL's and put them under c:windowssystem32. I added the following entries in all mapisvc.ini files under [SERVICES] section SMPMS=Sample Message Store MSLMS=Sample Local Message Store I added the following entires at the bottom of the files: [SMPMS] Providers=SMS PR_SERVICE_DLL_NAME=smpms.dll PR_SERVICE_SUPPORT_FILES=smpms.dll PR_SERVICE_DELETE_FILES=smpms.dll PR_SERVICE_ENTRY_NAME=SMSServiceEntry PR_RESOURCE_FLAGS=SERVICE_NO_PRIMARY_IDENTITY [SMS] PR_PROVIDER_DLL_NAME=smpms.dll PR_RESOURCE_TYPE=MAPI_STORE_PROVIDER PR_RESOURCE_FLAGS=STATUS_DEFAULT_STORE PR_PROVIDER_DISPLAY=MAPI Sample Message Store PR_MDB_PROVIDER=385d475fecf1cd1193dc5aab3C478437 [MSLMS] Providers=MS_LMS PR_SERVICE_DLL_NAME=MSLMS.DLL PR_SERVICE_ENTRY_NAME=ServiceEntry PR_SERVICE_SUPPORT_FILES=MSLMS.DLL PR_SERVICE_DELETE_FILES=MSLMS.DLL PR_RESOURCE_FLAGS=SERVICE_NO_PRIMARY_IDENTITY WIZARD_ENTRY_NAME=WizardEntry [MS_LMS] PR_PROVIDER_DLL_NAME=MSLMS.DLL PR_RESOURCE_TYPE=MAPI_STORE_PROVIDER PR_RESOURCE_FLAGS=STATUS_DEFAULT_STORE PR_PROVIDER_DISPLAY=Sample Local Message Store PR_DISPLAY_NAME=Sample Mailbox

  • Anonymous
    October 28, 2005
    nirl, If you're using the MSLMS sample linked from here, there's an export on there called MergeWithMAPISVC. It takes care of adding the appropriate entries for MSLMS to the right MAPISVC.INF file. You can invoke it like this: rundll32 mslms32.dll MergeWithMAPISVC. Conversely, there's also a RemoveFromMAPISVC function. You can examine both of these functions to determine exactly what you should be putting in the MAPISVC.INF file. Steve

  • Anonymous
    August 22, 2007
    A while back, I posted an article about the fixes Jason and I had to make to the MSLMS sample message

  • Anonymous
    August 15, 2008
    The first answer I give to customers asking for tips on making their store provider work with the latest