September, 2004

A while back, I posted an article about the fixes Jason and I had to make to the MSLMS sample message store to get it to load under Outlook 2003. Since then, I've received numerous requests that I post the changes. I wasn't ignoring the requests - I've just been busy adding features to MFCMAPI (more on that later).

Before I posted the code, I wanted to scrub it once more for obvious defects. We have some tools here which can point out potential bugs in your code, like dereferencing a pointer without first checking that it's not NULL. I was amazed at the volume of errors these scripts found in the sample. Even though most of these errors were trivial to fix, the number of them made for slow goings.

Anyway, here's the updated code. Fair warning: There's no warrenty whatsoever implied in this code. USE THIS CODE AT YOUR OWN RISK!

Todo list:

• Scrub each individual function for coding errors - make sure all parameters are checked and all variables properly initialized
• Remove all old tracing code and replace it with something more modern
• Remove all code wrapped in assert/verify macros and replace with real error handling
• Remove all gotos
• Remove dead code
• Add error handling for all function calls
• Replace all string handling functions with equivalent StrSafe functions
• Revisit my fix for the heap management issues

I'll post updates as I make major changes and bug fixes. I may create a workspace for this on gotdotnet if I see enough interest in it. Until I do, send any bug reports to me.

[edit - crediting JasonJoh for the work he did on this]

I wrote these rules out while debugging a crash in another MS product:

1. All threads which use MAPI must call MAPIInitialize before doing any MAPI.
2. All threads which use MAPI must call MAPIUninitialize before ending.
3. No thread should ever call MAPIUninitialize if it didn't already call MAPIInitialize.
4. If MAPI_MULTITHREAD_NOTIFICATIONS is not used, the first thread to call MAPIInitialize should live longer than all other MAPI threads and should be the last to call MAPIUninitialize.

I won't name the app, but it violated all 4 rules.

Known consequences of violating these rules:

1. MAPI just can't work on a thread that hasn't been initialized. All MAPI calls will fail.
2. Memory leak.
3. Either a crash or 'mysterious' errors. Thread A initializes MAPI and starts doing some work. Thread B then calls MAPIUninitialize. If no other thread has initialized MAPI, then MAPI assumes everyone is done with it and cleans up. Depending on the timing, thread A will either crash or start getting failures in MAPI calls.
4. When MAPI_MULTITHREAD_NOTIFICATIONS is not used, MAPI assumes it can tie the notification thread to the thread on which MAPIInitialize was first called. When this thread goes away, a pointer kept by the notification thread is invalidated, leading to a crash the next time we process a notification.