Share via


Enter the 64 Bit MAPI Dragon

Up until today, the first rule of 64 bit MAPI was we don’t talk about 64 bit MAPI. But now we can talk about it. 64 bit MAPI has arrived!

We just released the Outlook 2010 MAPI Reference today. If you develop MAPI based applications, you’ll want to get the updated MAPI Headers that come with it. You’ll need these if you want to rebuild your application for 64 bit. We’ve also prepared an article on building MAPI applications for both 32 bit and 64 bit platforms. This article is based in part on my experience building MFCMAPI as a 64 bit application. Since we don’t provide a 64 bit mapi32.lib, to build a 64 bit MAPI application you’re going to have to use explicit linking, building on the documentation we included in the Outlook 2007 MAPI reference.

Oh yeah – that reminds me – MFCMAPI builds as a 64 bit application! Actually, it’s been possible to build MFCMAPI as 64 bit for years. I slipped those project types in a long time ago and have been quietly maintaining them, even before I had an actual 64 bit build of MAPI I could test against. The next release of MFCMAPI will include a 64 bit build of the project, but if you want a 64 build now, just download the source and build it yourself.

Enjoy!

Comments

  • Anonymous
    July 13, 2009
    "More properties—Documentation for an additional 38 tagged properties and named properties has been added to this release." Well, at least we got a count of new properties :)  Any word on what these properties are? Thanks!

  • Anonymous
    July 13, 2009
    This sounds like progress to me. I have one small question which is that for years Microsoft have warned developers not to use the Outlook version of MAPI for serious MAPI applicatons such as server side applications. Are you now saying Outlook MAPI is safe for such applications?

  • Anonymous
    July 13, 2009
    Excellent stuff, great to hear this - are there any plans for a 64-bit standalone MAPI download as well? :-)

  • Anonymous
    July 13, 2009
    Very interesting! It was the case some time ago that Outlook MAPI was considered unsuitable for intense, multi-threaded MAPI applications, and that downloadable MAPI should be used instead. I assume that's still the case? If so, it's a shame as it would be nice to be able to run busy MAPI services as 64 bit apps, and I don't suppose the downloadable MAPI team are going to rebuild as a 64 bit library any time soon. Thanks for the update, Oliver

  • Anonymous
    July 14, 2009
    Considering Outlook's MAPI is the only one seeing active development, I would say the old preference of Exchange's MAPI over Outlook's MAPI no longer applies. Outlook itself does some intense, multi-threaded MAPI work. There are NO plans for a 64 bit MAPI download. The 32 bit MAPI download will see no further development and will NOT be made available as 64 bit.

  • Anonymous
    July 15, 2009
    Excellent. Good to see Microsoft supporting Extended MAPI. This was the right thing to do.

  • Anonymous
    July 17, 2009
    Yes, absolutely excellent! For fast, in-depth and Exchange-Server-portable coding MAPI has always been the way to go. Good to hear that it lives on!

  • Anonymous
    August 26, 2009
    Do you know whether this version of MAPI would happily co-exist with the CLR in the same process and whether that'd be a supported configuration? Thanks

  • Anonymous
    October 09, 2009
    The comment has been removed

  • Anonymous
    October 09, 2009
    The comment has been removed

  • Anonymous
    November 04, 2009
    Hi Stephen, Interesting stuff! I have two questions: 1- With this new Outlook 2010 and associated MAPI, and since the downloadable MAPI won't be around for long, is it now ok to install Outlook 2010 on an Exchange server to get [64-bit] MAPI? (e.g. Exchange 2007/2010 Hub Transport). 2- Actually, would it have been ok to install Outlook 2007? Thanks, and regards

  • Anonymous
    November 04, 2009
    Phillipe - definitely yes on the second question (Outlook 2007). Outlook 2010 isn't officially out yet, so I can't say it would be supportable right now to install it on the server for 64 bit MAPI, but most likely it will be supported come RTM.

  • Anonymous
    January 07, 2010
    Is the offline API (introduced with OL2003) still supported on 64 bit MAPI with Outlook 2010? I ask because I can get it work on 32 bit Outlook, but not 64 bit?

  • Anonymous
    January 07, 2010
    I wouldn't expect it to not work.

  • Anonymous
    February 16, 2010
    Steve, is there a reason _WIN64 is not defined in MFCMAPI c++/preprocessor section ( for x64 configurations )?  I looked quickly through new MAPI headers and some of them actually look for the #define. Thanks.

  • Anonymous
    February 16, 2010
    My code predates (and in some cases, informs) those new headers. Lemme know if you find something not working in 64 bit that would be fixed by adding _WIN64.

  • Anonymous
    February 16, 2010
    The only thing I see that would break would be if someone hits #defines below.  You are not using them now...  but mostly I was wondering about the best practices... #if defined (_WIN64) && defined (AMD64) #define szScCreateConversationIndex "ScCreateConversationIndex" #elif defined (_WIN32) && defined (X86) #define szScCreateConversationIndex "_ScCreateConversationIndex@16" #else #error "Unknown Platform: MAPI is currently supported on Win32/X86 and Win64/AMD64" #endif #if defined (_WIN64) && defined(AMD64) #define szHrDispatchNotifications "HrDispatchNotifications" #elif defined (_WIN32) && defined (X86) #define szHrDispatchNotifications "_HrDispatchNotifications@4" #else #error "Unknown Platform: MAPI is currently supported on Win32/X86 and Win64/AMD64" #endif

  • Anonymous
    February 16, 2010
    I just took a look at the project and _WIN64 does get defined for a 64 bit build. Check out the string for IDS_EDMAPIINITIALIZEFAILED which flips based on it.

  • Anonymous
    February 17, 2010
    _WIN64 is defined in MFCMAPI under Resource pre-processor( Properties->resources tab->preprocessor definitions). It's not defined under C++ pre-processor definitions ( so it would not be pulled into the code, I believe ).  In any case, your first reply pretty much answered my question. Thank you.