我有一个应用程序(用 C++ 和 MFC 编写，但我认为这不是特别相关)嵌入了 Internet Explorer ActiveX WebBrowser 控件以显示一些 HTML 页面。一项要求始终是使用应用程序的字体名称和大小设置作为 HTML 的默认设置，而不是 Internet Exporer 的默认设置。

为此，应用程序实现了 IDocHostUIHandler2 COM 接口(interface)，并将其传递给 WebBrowser 控件。这会导致控件调用应用程序的 GetOptionKeyPath 实现。 ，它允许应用程序设置 WebBrowser 控件从中获取其设置的注册表位置。借助 Sysinternals 的工具来查看 IE 使用哪些键来查找字体名称和大小，这足以满足我的需要。

但是，Internet Explorer 9 的出现却让人大吃一惊:在我测试过的所有安装了 IE9 的机器上，WebBrowser 控件使用自己的设置，忽略应用程序的注册表位置。使用调试器进行的测试表明 WebBrowser 控件从不调用提供的 GetOptionKeyPath。

更多的实验表明 IE9 WebBrowser 控件正在调用类似(但不相同)的 GetOverrideKeyPath方法:据称这提供了一种覆盖 IE 设置的方法，同时如果在注册表的相关部分没有找到任何内容，则回退到 IE 的实际设置。不幸的是，这有两个问题:1) 这不是我想要的，以及 2) 在转到 IE 默认注册表设置之前，IE9 并不总是检查 GetOverrideKeyPath 注册表位置。

查看 GetOptionKeyPath MSDN page有一些类似的投诉，但没有解决方案。有没有人找到一种干净的方法来说服 WebBrowser 控件恢复到实际调用 GetOptionKeyPath 的 IE9 之前的行为？

最佳答案

我想出了一个 hack 来解决这个问题，但我应该警告你:它并不漂亮。如果你很容易冒犯现在就停止阅读......

由于似乎没有办法让 IE9 使用 IDocHostUIHandler::GetOptionKeyPath() 方法，我使用 SysInternals 的工具来查看哪些 IE9 DLL 访问了注册表的相关部分以加载 IE9 设置。这揭示了唯一的罪魁祸首是“mshtml.dll”和“iertutil.dll”，它们都调用了 RegOpenKeyExW()。

当时的计划是在初始化 WebBrowser 控件之前加载这些 DLL，并修补它们以便将调用重定向到我的代码，在这里我可以使用 dbghelp.dll 隐瞒我打开的注册表项。因此，首先，在初始化 WebBrowser 控件之前:

if (theApp.GetIEVersion() >= 9.0)
{
  HMODULE advadi = ::LoadLibrary("advapi32.dll");
  HMODULE mshtml = ::LoadLibrary("mshtml.dll");
  HookApiFunction(mshtml,advadi,"advapi32.dll","RegOpenKeyExW",(PROC)HookRegOpenKeyExW);
  HMODULE iertutil = ::LoadLibrary("iertutil.dll");
  HookApiFunction(iertutil,advadi,"advapi32.dll","RegOpenKeyExW",(PROC)HookRegOpenKeyExW);
}

现在，执行扫描 DLL 导入地址表和修补请求函数的邪恶工作的代码(省略了错误处理以降低代码大小):

void HookApiFunction(HMODULE callingDll, HMODULE calledDll, const char* calledDllName, const char* functionName, PROC newFunction)
{
  // Get the pointer to the 'real' function
  PROC realFunction = ::GetProcAddress(calledDll,functionName);

  // Get the import section of the DLL, using dbghelp.dll's ImageDirectoryEntryToData()
  ULONG sz;
  PIMAGE_IMPORT_DESCRIPTOR import = (PIMAGE_IMPORT_DESCRIPTOR)
    ImageDirectoryEntryToData(callingDll,TRUE,IMAGE_DIRECTORY_ENTRY_IMPORT,&sz);

  // Find the import section matching the named DLL
  while (import->Name)
  {
    PSTR dllName = (PSTR)((PBYTE)callingDll + import->Name);
    {
      if (stricmp(dllName,calledDllName) == 0)
       break;
    }
    import++;
  }
  if (import->Name == NULL)
    return;

  // Scan the IAT for this DLL
  PIMAGE_THUNK_DATA thunk = (PIMAGE_THUNK_DATA)((PBYTE)callingDll + import->FirstThunk);
  while (thunk->u1.Function)
  {
    PROC* function = (PROC*)&(thunk->u1.Function);
    if (*function == realFunction)
    {
      // Make the function pointer writable and hook the function
      MEMORY_BASIC_INFORMATION mbi;
      ::VirtualQuery(function,&mbi,sizeof mbi);
      if (::VirtualProtect(mbi.BaseAddress,mbi.RegionSize,PAGE_READWRITE,&mbi.Protect))
      {
        *function = newFunction;
        DWORD protect;
        ::VirtualProtect(mbi.BaseAddress,mbi.RegionSize,mbi.Protect,&protect);
        return;
      }
    }
    thunk++;
  }

最后，我修补了 DLL 以在我的代码中调用的函数，代替了 RegOpenKeyExW():

LONG WINAPI HookRegOpenKeyExW(HKEY hKey, LPCWSTR lpSubKey, DWORD ulOptions, REGSAM samDesired, PHKEY phkResult)
{
  static const wchar_t* ieKey = L"Software\\Microsoft\\Internet Explorer";

  // Never redirect any of the FeatureControl settings
  if (wcsstr(lpSubKey,L"FeatureControl") != NULL)
    return ::RegOpenKeyExW(hKey,lpSubKey,ulOptions,samDesired,phkResult);

  if (wcsnicmp(lpSubKey,ieKey,wcslen(ieKey)) == 0)
  {
    // Redirect the IE settings to our registry key
    CStringW newSubKey(m_registryPath);
    newSubKey.Append(lpSubKey+wcslen(ieKey));
    return ::RegOpenKeyExW(hKey,newSubKey,ulOptions,samDesired,phkResult);
 }
 else
   return ::RegOpenKeyExW(hKey,lpSubKey,ulOptions,samDesired,phkResult);
}

令人吃惊的是，这个可怕的技巧居然奏效了。但是，Microsoft，如果您正在收听，请在 IE10 中正确修复此问题。

关于windows - 使用 IE9 嵌入 WebBrowser 控件时覆盖 IE 设置，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8850911/