Some confusions regarding FGetComponentPath

Jul 28, 2014 at 11:11 AM
Edited Jul 30, 2014 at 10:54 AM
Hi Team,

There are many confusions in my mind regarding FGetComponentPath.

1) If is Outlook is not installed but some other client, eg, ThunderBird, then should MSIComponentID and MSIApplicationLCID be there to get the custom version of MAPI. I am following How to: Choose a Specific Version of MAPI to Load. I am asking this because, it is not necessary that n number of email clients would be having these three registry keys (as mentioned in the link).

2) Is loading custom version of MAPI necessary? mapi32.dll and mapistub.dll wouldn't do the work? They are also having the same functions as custom version of MAPI.

3) In the documentation (link) given above, and also in MFCMAPI, for FGetComponentPathType, you have first loaded mapi32.dll and if that fails, you have loaded mapistub.dll. What is the difference between the two, i.e., mapi32.dll and mapistub.dll? Why have you checked if mapi32.dll is not loaded, then load mapistub.dll? Is there any condition that loading mapi32.dll will fail and mapistub.dll will pass. I am asking this because it isn't making sense.

4) I made an application using the method given in the link mentioned above. I thought of checking if I can build the same application if I loaded mapi32.dll instead of custom MAPI implementation and it worked fine. The same applies to mapistub.dll also. Then why is loading custom MAPI necessary? We could have loaded mapi32.dll and/or mapistub.dll also.

Kindly ask for clarifications if any point is not properly understood and also enlighten me on the above points.

Thanks & regards,

Talib Hussain.
Jul 28, 2014 at 1:43 PM
mapi32.dll is the core MAPI stub library you should be loading, unless you know you only wish to work with Outlook's MAPI (or the MAPI of some other product). Because we didn't always used to have a MAPI stub library, some products still try to replace mapi32.dll with their own implementation of mapi32.dll. So, we also keep a copy of this library as mapistub.dll. That's why, if we find we can't work with mapi32.dll, we try mapistub.dll instead, in case mapi32.dll has been clobbered.

As for why you'd want to get the underlying MAPI implementation library, for most basic MAPI operations, you're right, mapi32.dll is sufficient. But Outlook's MAPI does implement some exports that aren't part of the core MAPI specification. So you might want to find Outlook's library so you can load exports from it. Other MAPI clients may provide their own custom exports you also wish to code against.
Jul 29, 2014 at 4:46 AM
If mapi32.dll is replaced by MAPI of some other product, then also it is loaded (in GetComponentPath() in StubUtils.cpp). I have replaced mapi32.dll with other dll and it is loaded and after that it uses GetProcAddress and GetProcAddress fails. Instead it should first load mapi32.dll and try GetProcAddress and if that fails, load mapistub.dll and use GetProcAddress. What do you say?
Jul 29, 2014 at 1:46 PM
That might be a potential improvement. But if mapi32.dll has ben replaced, you might be better off running fixmapi.exe to fix it.
Jul 30, 2014 at 10:52 AM
Edited Jul 30, 2014 at 10:57 AM

But I was speaking about the code in MFCMAPI. We could do it manually using fixmapi.exe. In MFCMAPI, FixMAPI or fixmapi.exe isn't used. So I was saying about checking if FGetComponentPath is present in mapi32.dll which was replaced by other email client. If it fails then load mapistub.dll and then check for FGetComponentPath.

What is done in MFCMAPI is mapi32.dll is loaded. If it fails then load mapistub.dll and use FGetComponentPath.

In such cases mapi32.dll is loaded even if it is replaced by other email client, mapistub.dll isn't loaded and FGetComponentPath fails.

I got fixmapi.exe in C:\WINDOWS\system32 and C:\WINDOWS\system32\dllcache after searching it in the drive where windows is installed.
Jul 30, 2014 at 2:35 PM
I get that, but this is an incredibly rare scenario nowadays. I probably won't be making this change.
Jul 31, 2014 at 4:08 AM
There was a mistake that I made in programming because of which I got wrong results. Now, I have rectified that mistake. I noticed that if mapi.dll or mapistub.dll is loaded then, pfnMAPIInitialize() fails. And if the dll pointed by HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\ExchangeMAPI\DLLPathEx is loaded then the function fails at pfnMAPILogonEx() and the message is as shown in Fun With the MAPI Spooler. Sorry.

Can you tell some more about this message?
Jul 31, 2014 at 3:05 PM
I'd probably have to debug the scenario to tell you more than what you already know.