Where did MAPISVC.INF go?


[This is now documented here: http://msdn.microsoft.com/en-us/library/bb820993.aspx]

There’s a KB article (http://support.microsoft.com/kb/229700) that discusses how to use FGetComponentPath to find MAPISVC.INF. It has two major problems:

  • It doesn’t work well in most non-English locales
  • It doesn’t work at all with Outlook 2007

The code below corrects both problems. Here’s why:

Non-English

I’ll admit – I never fully understood this before. The documentation for FGetComponentPath indicates the szQualifier should be “(t)he MSIApplicationLCID or MSIOfficeLCID subkey described in Setting Up the MSI Keys for Your MAPI DLL.” I must have skimmed over that comment hundreds of times before it sunk in. It means to go get those keys and pass what’s in them to FGetComponentPath! This will allow FGetComponentPath to use the data in those keys to help locate where the localized copy of the component (MAPI) was installed. If szQualifier is left out, it will try to find the installed component using the system’s default user LCID, then the system’s default LCID, then a hard coded value of 1033 (English-US). This is why the code in the article would work in English locales but not elsewhere.

Outlook 2007

Here, again, it pays to read the documentation for FGetComponentPath (something I’m guilty of not doing). It says szComponent should be “(t)he MSIComponentID reg key described in Mapi32.dll Stub Registry Settings.” The code in the article ignored this and instead passed “{473FF9A0-D659-11D1-A4B2-006008AF820E}”, which was the component ID of MAPISVC.INF on Outlook 2000. This worked fine when the article was written, and continued to work up through Outlook 2003. However, Outlook 2007 no longer installs MAPISVC.INF (though it will use it if it finds it), so this component ID stops working. The fix is to pass “{FF1D0740-D227-11D1-A4B0-006008AF820E}”, which is the component ID of MAPI that you’d get if you read the MSIComponentID key. In the code below, I hard coded this ID, but it would be better to try and read it from the registry first and only fall back to the hard coded string on failure.

This code should work with all versions of Outlook, but I’ve only tested it with Outlook 2003 and 2007.

// HrGetRegMultiSZValueA
// Get a REG_MULTI_SZ registry value - allocating memory using new to hold it.
void HrGetRegMultiSZValueA(
   IN HKEY hKey, // the key.
   IN LPCSTR lpszValue, // value name in key.
   OUT LPVOID* lppData) // where to put the data.
{
   *lppData = NULL;
   DWORD dwKeyType = NULL;      
   DWORD cb = NULL;
   LONG lRet = 0;
   
   // Get its size
   lRet = RegQueryValueExA(
      hKey,
      lpszValue,
      NULL,
      &dwKeyType,
      NULL,
      &cb);

   if (ERROR_SUCCESS == lRet && cb && REG_MULTI_SZ == dwKeyType)
   {
      *lppData = new BYTE[cb];
      
      if (*lppData)
      {
         // Get the current value
         lRet = RegQueryValueExA(
            hKey, 
            lpszValue, 
            NULL, 
            &dwKeyType, 
            (unsigned char*)*lppData, 
            &cb);
         
         if (ERROR_SUCCESS != lRet)
         {
            delete[] *lppData;
            *lppData = NULL;
         }
      }
   }
}

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

///////////////////////////////////////////////////////////////////////////////
// Function name   : GetMAPISVCPath
// Description       : This will get the correct path to the MAPISVC.INF file.
// Return type      : void 
// Argument         : LPSTR szMAPIDir - Buffer to hold the path to the MAPISVC file.
//                    ULONG cchMAPIDir - size of the buffer
void GetMAPISVCPath(LPSTR szMAPIDir, ULONG cchMAPIDir)
{
   HRESULT hRes = S_OK;
   UINT uiRet = 0;
   LONG lRet = 0;
   BOOL bRet = true;
   
   szMAPIDir[0] = '\0'; // Terminate String at pos 0 (safer if we fail below)
   
   CHAR szSystemDir[MAX_PATH+1] = {0};
   
   // Get the system directory path
   // (mapistub.dll and mapi32.dll reside here)
   uiRet = GetSystemDirectoryA(szSystemDir, MAX_PATH);
   if (uiRet > 0)
   {
      CHAR szDLLPath[MAX_PATH+1] = {0};
      
      hRes = StringCchPrintfA(szDLLPath, MAX_PATH+1, "%s\\%s", 
         szSystemDir, "mapistub.dll");
      if (SUCCEEDED(hRes))
      {
         LPFGETCOMPONENTPATH pfnFGetComponentPath = NULL;
         
         HMODULE hmodStub = 0;
         HMODULE hmodMapi32 = 0;
         
         // Load mapistub.dll
         hmodStub = LoadLibraryA(szDLLPath);
         if (hmodStub)
         {   
            // Get the address of FGetComponentPath from the mapistub
            pfnFGetComponentPath = (LPFGETCOMPONENTPATH)GetProcAddress(
               hmodStub, "FGetComponentPath");
         }
         
         // If we didn't get the address of FGetComponentPath
         // try mapi32.dll
         if (!pfnFGetComponentPath)
         {
            hRes = StringCchPrintfA(szDLLPath, MAX_PATH+1, "%s\\%s",
               szSystemDir, "mapi32.dll");
            if (SUCCEEDED(hRes))
            {
               // Load mapi32.dll
               hmodMapi32 = LoadLibraryA(szDLLPath);
               if (hmodMapi32)
               {
                  // Get the address of FGetComponentPath from mapi32
                  pfnFGetComponentPath = (LPFGETCOMPONENTPATH)GetProcAddress(
                     hmodMapi32, "FGetComponentPath");
               }
            }
         }
         if (pfnFGetComponentPath)
         {
            LPSTR szAppLCID = NULL;
            LPSTR szOfficeLCID = NULL;
            HKEY hMicrosoftOutlook = NULL;
            
            lRet = RegOpenKeyEx(
               HKEY_LOCAL_MACHINE,
               _T("Software\\Clients\\Mail\\Microsoft Outlook"),
               NULL,
               KEY_READ,
               &hMicrosoftOutlook);
            
            if (ERROR_SUCCESS == lRet && hMicrosoftOutlook)
            {
               HrGetRegMultiSZValueA(hMicrosoftOutlook, "MSIApplicationLCID", (LPVOID*) &szAppLCID);
               HrGetRegMultiSZValueA(hMicrosoftOutlook, "MSIOfficeLCID", (LPVOID*) &szOfficeLCID);
            }
            
            if (szAppLCID)
            {
               bRet = pfnFGetComponentPath(
                  "{FF1D0740-D227-11D1-A4B0-006008AF820E}", szAppLCID, szMAPIDir, cchMAPIDir, true);
            }
            if ((!bRet || szMAPIDir[0] == _T('\0')) && szOfficeLCID)
            {
               bRet = pfnFGetComponentPath(
                  "{FF1D0740-D227-11D1-A4B0-006008AF820E}", szOfficeLCID, szMAPIDir, cchMAPIDir, true);
            }
            if (!bRet || szMAPIDir[0] == _T('\0'))
            {
               bRet = pfnFGetComponentPath(
                  "{FF1D0740-D227-11D1-A4B0-006008AF820E}", NULL, szMAPIDir, cchMAPIDir, true);
            }
            
            // We got the path to msmapi32.dll - need to strip it
            if (bRet && szMAPIDir[0] != _T('\0'))
            {
               LPSTR lpszSlash = NULL;
               LPSTR lpszCur = szMAPIDir;
               
               for (lpszSlash = lpszCur; *lpszCur; lpszCur = lpszCur++)
               {
                  if (*lpszCur == _T('\\')) lpszSlash = lpszCur;
               }
               *lpszSlash = _T('\0');
            }

            delete[] szOfficeLCID;
            delete[] szAppLCID;
            if (hMicrosoftOutlook) RegCloseKey(hMicrosoftOutlook);      
         }
            
            // If FGetComponentPath returns FALSE or if
            // it returned nothing, or if we never found an
            // address of FGetComponentPath, then
            // just default to the system directory
         if (!bRet || szMAPIDir[0] == '\0')
         {
            hRes = StringCchPrintfA(
               szMAPIDir, cchMAPIDir,"%s", szSystemDir);
         }
         
         if (szMAPIDir[0] != _T('\0'))
         {
            hRes = StringCchPrintfA(
               szMAPIDir, cchMAPIDir, "%s\\%s", szMAPIDir, "MAPISVC.INF");
         }
         
         if (hmodMapi32) FreeLibrary(hmodMapi32);
         if (hmodStub) FreeLibrary(hmodStub);
      }
   }   
}
Comments (18)

  1. Henry Gusakovsky says:

    Eventually an official answer.

    It proves that we are on the right way 🙂

    Thank’s Stephen.

  2. Jules Colding says:

    Would the above also work for mapisvc.inf as installed by Exchange?

  3. Jules – Exchange doesn’t use fGetComponentPath or any of the MSI stuff. It just puts/looks for the file in the system directory. If I didn’t screw it up, the code above should fall back correctly to system directory.

  4. Miro says:

    I’ve tried using mfcmapi and I have one problem with it:

    when opening email message with "Open Message" menu item, I get the Outloook form with "Reply" button available. But when pressing reply, though, I get new form where "Send" button is disabled !!???

    Additionally, If I open email message with "Execute Verb on Form" and try verbs 100, 102, 103, 104 or 107  – I always get the form with "Send" button disabled !!???

    I am using Outlook 2003.

    Is it a bug or some security feature of Outlook?

    Basically this ruins the usability of the "open non modal" code that I am trying to reuse.

    Regards,

     Miro

  5. MFCMAPI only has a partial implementation of the form viewer classes. You might want to look at Goetter’s book.

  6. Merlin says:

    I could say: ‘Forget what’s said in KB article and follow documentation of FGetComponentPath, because it gives you all information you need. ‘ You have to read all stuff (component ID and LCIDs) from registry. We use it this way for more then 2 years  without any problems.

    1. KB article is quite old

    2. FGetComponentPath is one of the undisclosed API functions (was a kind of secret thing 2 years ago).

  7. Merlin – FGetComponentPath has been documented for many years now (well more than 2). As for the rest of your comment – yeah – that’s exactly what I’m saying – the documentation explains all this and the code in the KB article needs work. That was the point of my post.

  8. I managed to waste half a morning figuring out something I’m supposed to already know. Dev asked if I

  9. Jeff Davis says:

    Sorry for the ignorance, but were do you input this code? I’m new to this environment! This would be a solution for why my Outlook 2007 will not update on KB935569, as it keeps looking for my mapisvc.inf. TIA, Jeff

  10. I don’t think this code is for you. If you’re having trouble applying a hotfix, call in to support to get someone to look at it.

  11. Saju says:

    I tried using some portions of the above code to see if it works with Chinese Outlook (2003) and it didn’t. I ended up using the DLLPathEx subkey to find the path of msmapi32.dll. Any ideas of what could have been the problem

  12. One possibility is that I hardcoded the value "FF1D0740-D227-11D1-A4B0-006008AF820E" instead of reading it from the registry. Perhaps MSIComponentID has a different value for the Chinese SKU?

    When you say the code didn’t work – what did it do? Throw an error? Give a directory you didn’t expect? More details == better help.

  13. Saju says:

    I did think that could be the reason but the value for MSIComponentID in the registry is same as the one you specified in the post.

  14. Saju says:

    Sorry. Forgot to mention that it didn’t give any errors but the result was always an empty string.

  15. Hrmm – this might be a localization bug. It sounds vaguely familiar but I haven’t been able to turn up any bug reports on it. You might try calling in for support to get it investigated in depth.

  16. jos says:

    I also could not get FGetComponentPath to find the German version of Outlook 2007 MAPI DLL. Even if I use the ComponentId from the registry (which is the same as you hard coded). So it looks like there is no documented way to get the path of Outlook MAPI DLL for localized versions of Outlook 2007. Could you please give an advise how to solve this problem or at least confirm that this is not supported?

  17. Jos – download MFCMAPI (http://mfcmapi.codeplex.com) and try it out there. I’ve tweaked the code a bit since I wrote this article.

  18. Jos says:

    After I upgraded my German Outlook to SP2 the code worked.