• Sign in
 
  •  
  • MSDN Blogs
  • Microsoft Blog Images
  • More ...

  • Blog Home
  • About
  • Email Blog Author
  • Share this
  • RSS for posts
  • Atom
  • RSS for comments
  • CDO (25)
  • Code Snippet (43)
  • Custom Providers (17)
  • Debugging (7)
  • DevMsgTeam (301)
  • Documentation (109)
  • DST (8)
  • EWS (7)
  • Exchange (109)
  • Gotchas (97)
  • Hotfix (28)
  • MAPI (240)
  • MAPI Download (54)
  • MFCMAPI (101)
  • MSDN (59)
  • Non Dev (11)
  • OOM (17)
  • Outlook (171)
  • Outlook 2007 Auxiliary Reference (45)
  • Outlook Integration API (12)
  • Protocol Docs (20)
  • PST/OST (23)
  • Referrals (8)
  • Vista (12)
  • WrapPST (18)
Links:
  • Download MFCMAPI
  • MFCMAPI on Facebook
  • Troubleshooting Outlook Crashes
  • Office Update Center
  • Developer Messaging Team Blog
This site is provided "AS IS" with no warranties, and confers no rights. Use of included code samples are subject to the terms specified in the Terms of Use.
Archives
  • May 2013 (3)
  • April 2013 (1)
  • March 2013 (2)
  • February 2013 (2)
  • January 2013 (2)
  • December 2012 (4)
  • November 2012 (2)
  • October 2012 (2)
  • September 2012 (1)
  • August 2012 (3)
  • June 2012 (2)
  • May 2012 (1)
  • April 2012 (3)
  • March 2012 (3)
  • February 2012 (3)
  • January 2012 (1)
  • December 2011 (3)
  • November 2011 (1)
  • October 2011 (3)
  • September 2011 (1)
  • August 2011 (1)
  • July 2011 (4)
  • June 2011 (3)
  • May 2011 (3)
  • April 2011 (3)
  • March 2011 (5)
  • February 2011 (1)
  • January 2011 (2)
  • December 2010 (1)
  • November 2010 (4)
  • October 2010 (1)
  • September 2010 (3)
  • August 2010 (5)
  • July 2010 (3)
  • June 2010 (3)
  • May 2010 (1)
  • April 2010 (3)
  • March 2010 (3)
  • February 2010 (3)
  • January 2010 (2)
  • December 2009 (3)
  • November 2009 (5)
  • October 2009 (4)
  • September 2009 (5)
  • August 2009 (5)
  • July 2009 (11)
  • June 2009 (6)
  • May 2009 (5)
  • April 2009 (3)
  • March 2009 (18)
  • February 2009 (10)
  • January 2009 (3)
  • December 2008 (2)
  • November 2008 (2)
  • October 2008 (5)
  • September 2008 (4)
  • August 2008 (10)
  • July 2008 (6)
  • June 2008 (8)
  • May 2008 (2)
  • April 2008 (4)
  • March 2008 (2)
  • February 2008 (2)
  • January 2008 (5)
  • December 2007 (3)
  • November 2007 (2)
  • October 2007 (3)
  • September 2007 (1)
  • August 2007 (4)
  • July 2007 (5)
  • June 2007 (3)
  • May 2007 (4)
  • April 2007 (1)
  • March 2007 (6)
  • February 2007 (3)
  • January 2007 (2)
  • December 2006 (4)
  • November 2006 (3)
  • October 2006 (1)
  • August 2006 (1)
  • June 2006 (5)
  • May 2006 (5)
  • December 2005 (1)
  • November 2005 (4)
  • October 2005 (2)
  • September 2005 (1)
  • April 2005 (3)
  • December 2004 (2)
  • September 2004 (2)
  • August 2004 (3)
  • July 2004 (3)

Where did MAPISVC.INF go?

MSDN Blogs > SGriffin's MAPI Internals > Where did MAPISVC.INF go?

Where did MAPISVC.INF go?

Rate This
Stephen Griffin - MSFT
18 Jan 2007 2:02 PM
  • Comments 18

[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);
      }
   }   
}
  • 18 Comments
Outlook, MAPI, Code Snippet, MFCMAPI, Outlook 2007 Auxiliary Reference, DevMsgTeam, MSDN
Comments
  • Henry Gusakovsky
    18 Jan 2007 2:16 PM

    Eventually an official answer.

    It proves that we are on the right way :)

    Thank's Stephen.

  • Jules Colding
    18 Jan 2007 4:28 PM

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

  • Stephen Griffin - MSFT
    18 Jan 2007 5:23 PM

    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.

  • Miro
    25 Jan 2007 3:45 AM

    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

  • Stephen Griffin - MSFT
    25 Jan 2007 10:58 AM

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

  • Merlin
    9 Feb 2007 5:43 AM

    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).

  • Stephen Griffin - MSFT
    9 Feb 2007 9:48 AM

    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.

  • SGriffin's [MSFT] WebLog
    9 Jul 2007 11:15 AM

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

  • Jeff Davis
    27 Sep 2007 8:56 PM

    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

  • Stephen Griffin - MSFT
    28 Sep 2007 8:21 AM

    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.

  • Saju
    28 Sep 2007 9:21 AM

    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

  • Stephen Griffin - MSFT
    28 Sep 2007 9:36 AM

    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.

  • Saju
    30 Sep 2007 11:56 PM

    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.

  • Saju
    1 Oct 2007 1:33 AM

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

  • Stephen Griffin - MSFT
    1 Oct 2007 9:03 AM

    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.

Page 1 of 2 (18 items) 12
Leave a Comment
  • Please add 2 and 5 and type the answer here:
  • Post
  • © 2013 Microsoft Corporation.
  • Terms of Use
  • Trademarks
  • Privacy & Cookies
  • Report Abuse
  • 5.6.426.415