Problem with determination of path to MSMAPI32.DLL

[Petr Nehéz]

We are developing application which is based on MAPI and communicates
with our addin loaded in Outlook. Then we have one company customer
and I have problem at one user with determination of path to
MSMAPI32.DLL (I am not using MAPI32.DLL because it popups message box
when Outlook is not set as default email program.).

The problem is this:
There is Office 2003 installed (installation language is English) at
this time, the user has tried Office 2007 some time ago but then he
reverted it with some company's installer back to Office 2003.
Then there is another language pack installed for Office 2003 -
Hebrew. Current language of Outlook is Hebrew - Outlook is started
smoothly in Hebrew language.
There are 2 folders in folder "C:\Program Files\Common Files\System
\MSMAPI" - 1033 (for English) and 1037 (Hebrew).
In my application I read registry key "HKEY_LOCAL_MACHINE\Software
\Clients\Mail\Microsoft Outlook" and value "MSIApplicationLCID". I
decode this value and then I try to read compiled paths - for this
case it is "HKEY_CURRENT_USER\Software\Policies\Microsoft\Office
\11.0\Outlook" and "HKEY_CURRENT_USER\Software\Microsoft\Office
\11.0\Outlook" and value "LastUILanguage". I read value 1037.

So I load 1037 version of MSMAPI32.DLL in my application.

But the problem is that Outlook loads 1033 (English) version of
MSMAPI32.DLL although it is being started in Hebrew so it should use
1037 version. And here the troubles come - I know that MAPI does not
like different versions loaded at same time.

How can I find out the correct path to MSMAPI32.DLL?
Does anybody (Dmitry or Steve) know more?

 

[Tom]

Hi Petr,

The following functionality has always worked for me. Got this function a
few years ago from some sample code somewhere.


typedef BOOL (STDAPICALLTYPE FGETCOMPONENTPATH)
(LPSTR szComponent,
LPSTR szQualifier,
LPSTR szDllPath,
DWORD cchBufferSize,
BOOL fInstall);
typedef FGETCOMPONENTPATH FAR * LPFGETCOMPONENTPATH;

void GetMAPISVCPath(LPSTR szMAPIDir, ULONG ulMAPIDir)
{
HINSTANCE hinstStub = NULL;

hinstStub = LoadLibrary(_T("mapistub.dll"));
if (!hinstStub)
{
hinstStub = LoadLibrary(_T("mapi32.dll"));
}

if (hinstStub)
{
LPFGETCOMPONENTPATH pfnFGetComponentPath;

pfnFGetComponentPath = (LPFGETCOMPONENTPATH)
GetProcAddress(hinstStub, "FGetComponentPath");

if (pfnFGetComponentPath)
{

if ((pfnFGetComponentPath("{473FF9A0-D659-11D1-A4B2-006008AF820E}",
NULL, szMAPIDir, ulMAPIDir, TRUE)) &&
szMAPIDir[0] != '\0')
{
// TODO: Add debug tracing to spit out the value
}
else
{
szMAPIDir[0] = '\0'; // Terminate String at pos 0.
}
}

FreeLibrary(hinstStub);
}
}


Regards,
Tom

 

[Petr Nehéz]

Hi Tom,

thank you, I also found these links:
http://msdn.microsoft.com/en-us/library/dd353278.aspx
http://msdn.microsoft.com/en-us/library/dd353277.aspx

Petr

Hi Petr,

The following functionality has always worked for me. Got this function a
few years ago from some sample code somewhere.

typedef BOOL (STDAPICALLTYPE FGETCOMPONENTPATH)
 (LPSTR szComponent,
 LPSTR szQualifier,
 LPSTR szDllPath,
 DWORD cchBufferSize,
 BOOL fInstall);
typedef FGETCOMPONENTPATH FAR * LPFGETCOMPONENTPATH;

void GetMAPISVCPath(LPSTR szMAPIDir, ULONG ulMAPIDir)
{
 HINSTANCE hinstStub = NULL;

 hinstStub = LoadLibrary(_T("mapistub.dll"));
 if (!hinstStub)
 {
  hinstStub = LoadLibrary(_T("mapi32.dll"));
 }

 if (hinstStub)
 {
  LPFGETCOMPONENTPATH pfnFGetComponentPath;

  pfnFGetComponentPath = (LPFGETCOMPONENTPATH)
   GetProcAddress(hinstStub, "FGetComponentPath");

  if (pfnFGetComponentPath)
  {

   if ((pfnFGetComponentPath("{473FF9A0-D659-11D1-A4B2-006008AF820E}",
    NULL, szMAPIDir, ulMAPIDir, TRUE)) &&
    szMAPIDir[0] != '\0')
   {
    // TODO: Add debug tracing to spit out the value
   }
   else
   {
    szMAPIDir[0] = '\0'; // Terminate String at pos 0.
   }
  }

  FreeLibrary(hinstStub);
 }

}

Regards,
Tom

We are developing application which is based on MAPI and communicates
with our addin loaded in Outlook. Then we have one company customer
and I have problem at one user with determination of path to
MSMAPI32.DLL (I am not using MAPI32.DLL because it popups message box
when Outlook is not set as default email program.).

The problem is this:
There is Office 2003 installed (installation language is English) at
this time, the user has tried Office 2007 some time ago but then he
reverted it with some company's installer back to Office 2003.
Then there is another language pack installed for Office 2003 -
Hebrew. Current language of Outlook is Hebrew - Outlook is started
smoothly in Hebrew language.
There are 2 folders in folder "C:\Program Files\Common Files\System
\MSMAPI" - 1033 (for English) and 1037 (Hebrew).
In my application I read registry key "HKEY_LOCAL_MACHINE\Software
\Clients\Mail\Microsoft Outlook" and value "MSIApplicationLCID". I
decode this value and then I try to read compiled paths - for this
case it is "HKEY_CURRENT_USER\Software\Policies\Microsoft\Office
\11.0\Outlook" and "HKEY_CURRENT_USER\Software\Microsoft\Office
\11.0\Outlook" and value "LastUILanguage". I read value 1037.

So I load 1037 version of MSMAPI32.DLL in my application.

But the problem is that Outlook loads 1033 (English) version of
MSMAPI32.DLL although it is being started in Hebrew so it should use
1037 version. And here the troubles come - I know that MAPI does not
like different versions loaded at same time.

How can I find out the correct path to MSMAPI32.DLL?
Does anybody (Dmitry or Steve) know more?