Where did MAPISVC.INF go?
[This is now documented here: https://msdn.microsoft.com/en-us/library/bb820993.aspx]
There's a KB article (https://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
Anonymous
January 18, 2007
Eventually an official answer. It proves that we are on the right way :) Thank's Stephen.Anonymous
January 18, 2007
Would the above also work for mapisvc.inf as installed by Exchange?Anonymous
January 18, 2007
The comment has been removedAnonymous
January 24, 2007
The comment has been removedAnonymous
January 25, 2007
MFCMAPI only has a partial implementation of the form viewer classes. You might want to look at Goetter's book.Anonymous
February 08, 2007
The comment has been removedAnonymous
February 09, 2007
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.Anonymous
July 09, 2007
I managed to waste half a morning figuring out something I'm supposed to already know. Dev asked if IAnonymous
September 27, 2007
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, JeffAnonymous
September 28, 2007
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.Anonymous
September 28, 2007
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 problemAnonymous
September 28, 2007
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.Anonymous
September 30, 2007
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.Anonymous
September 30, 2007
Sorry. Forgot to mention that it didn't give any errors but the result was always an empty string.Anonymous
October 01, 2007
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.Anonymous
July 23, 2009
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?Anonymous
July 23, 2009
Jos - download MFCMAPI (http://mfcmapi.codeplex.com) and try it out there. I've tweaked the code a bit since I wrote this article.Anonymous
July 24, 2009
After I upgraded my German Outlook to SP2 the code worked.