I’m in the process of updating the Outlook 2007 MAPI Samples for Outlook 2010 and ran into something that deserves some clarification. Suppose you have a 32 bit application which uses MAPI and which links in mapi32.lib. In preparation for 64 bit MAPI, you decide to try rebuilding as a 64 bit app. You install the updated MAPI headers, point your installer at them, then try building a 64 bit flavor. The 64 bit compiler might catch a few type casting errors, which you fix, then it’s time to link.
Now – if you do what I did a couple days ago, you don’t mess with the linked library settings and just let it build. And if you have the Microsoft SDK installed, it might succeed. How is this possible, when mapi32.lib is a 32 bit library?
We look at the SDK for copies of mapi32.lib:
C:\Program Files\Microsoft SDKs>dir /s mapi32.libDirectory of C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib09/27/2007 03:20 PM 34,778 MAPI32.Lib1 File(s) 34,778 bytesDirectory of C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib\x6409/27/2007 03:20 PM 28,478 MAPI32.Lib1 File(s) 28,478 bytes
This is why the link succeeded, and this is the problem I’m here to warn you about. That 64 bit build of mapi32.lib shouldn’t exist. To put it another way: The 64 bit build of mapi32.lib is bad and should be avoided! Basically, the SDK team built and shipped this library without the involvement of Office. There were a number of changes which should have been made to get it ready for 64 bit MAPI, but weren’t made. We’re still investigating if it would be possible for Office to ship a 64 bit version of this library. But for now, if you want to build a 64 bit MAPI application, you have to explicitly link to MAPI.
BTW – this isn’t a problem for MFCMAPI, which hasn’t linked with mapi32.lib for years.