使用Visual C++开发IE浏览器工具条插件实战

本文还有配套的精品资源，点击获取

简介：开发浏览器插件是IT领域中提升用户浏览体验的重要技术手段。本文聚焦于利用Visual C++（VC）开发Internet Explorer（IE）的工具条插件（IE Toolbar），深入讲解如何通过COM组件模型构建可集成到IE中的功能扩展。项目以DLL形式实现，结合ATL库进行界面设计与事件处理，并通过实现IObjectWithSite、IDockingWindow等关键接口完成插件的注册与嵌入。配套源码“MotleyFool_src”提供了完整的开发参考，涵盖项目创建、UI设计、接口实现、注册机制及调试流程，帮助开发者掌握系统级浏览器扩展开发的核心技能。

IE浏览器插件开发：从零构建稳定高效的工具栏扩展

在企业级系统和金融行业的后台环境中，尽管现代浏览器已全面普及，但仍有大量关键业务依赖于IE浏览器及其插件生态。这类“老旧”技术之所以能长期存续，并非因为它们先进，而是因为在特定场景下——比如与本地安全控件、U盾驱动、CA证书服务深度集成时——它们提供了无可替代的底层控制能力。

想象一下这样一个画面：你坐在某银行的柜台前，柜员插入一张智能卡，点击网页上的“签名”按钮，弹出一个绿色边框的确认窗口，然后轻轻一按，交易完成。这个看似简单的操作背后，正是IE插件在默默工作。它穿越了浏览器的安全沙箱，调用了操作系统级别的API，完成了加密计算与身份认证。而这一切，都是通过一个小小的DLL文件实现的。

这就是我们今天要深入探讨的主题： 如何用Visual C++从头打造一个功能完整、稳定可靠的IE浏览器插件 。我们将不只讲“怎么做”，更要揭示“为什么这么设计”。从COM机制的本质，到ATL框架的巧妙封装；从注册表的神秘结构，到调试器如何穿透iexplore.exe进程；每一个细节都将被拆解、分析、重构。

准备好了吗？让我们一起走进Windows原生开发的世界，揭开IE插件那层略显陈旧却依然坚固的技术外衣。🧩💻🔍

开发环境搭建：为战斗准备武器库

任何一场战役的成功，都始于后勤保障。对于IE插件开发而言，这个“后勤”就是你的开发环境。别小看这一环，很多开发者第一次尝试编译插件就失败了，原因往往是工具链配置不当。

选对VS版本，少走十年弯路

虽然Visual Studio 2022听起来很新潮，但在IE插件领域， VS2019才是真正的王者 。特别是当你需要兼容Windows 7或IE8这类古董级系统时，v142工具集（MSVC 14.2）几乎是唯一选择。为什么？因为VS2022默认使用的v143工具集会引入一些新的运行时特性，在老系统上直接蓝屏不是开玩笑的 😵‍💫。

安装时一定要勾选这三个核心组件：

• 使用C++的桌面开发
• Windows SDK （建议10.0.19041及以上）
• ATL支持

忘了SDL检查吧，那是给新时代应用准备的。我们的战场是Win32原生世界，这里信奉的是多字节字符集（MBCS），不是Unicode。为啥？因为你永远不知道某个遗留系统的注册表里是不是还躺着一堆ANSI编码的键名。强制转Unicode？等着Access Violation吧！

💡 小贴士：装完后打开命令行敲 cl.exe ，如果看到编译器版本信息而不是“不是内部或外部命令”，说明环境变量已经就位，可以继续前进了。

SDK加载流程：谁动了我的头文件？

你有没有遇到过这种情况：代码写着写着，突然发现 exdisp.h 找不到？别慌，这通常是因为SDK路径没配好。在项目属性 → VC++目录 → 包含目录中，确保有这两条黄金路径：

$(WindowsSdkDir)Include\$(WindowsSDKVersion)\um
$(VC_IncludePath)

其中 um 指的是User Mode API，专门为我们这种用户态DLL准备的。至于那些必须链接的库，记住这张清单：

库名	用途
kernel32.lib	基础系统调用
user32.lib	窗口消息处理
gdi32.lib	图形绘制
advapi32.lib	注册表操作
ole32.lib	COM核心支持
oleaut32.lib	自动化类型支持
uuid.lib	GUID常量链接

这些可不是可选项，而是每一发子弹都要上膛的标配弹药。

Mermaid 流程图：SDK组件加载关系

graph TD
    A[Win32 DLL Project] --> B{Includes Headers}
    B --> C[exdisp.h]
    B --> D[ocidl.h]
    B --> E[atlbase.h]
    A --> F{Links Libraries}
    F --> G[ole32.lib]
    F --> H[uuid.lib]
    F --> I[user32.lib]
    G --> J[COM CoInitialize]
    H --> K[GUID Definition]
    I --> L[CreateWindowEx]

看懂了吗？你的DLL就像一座桥梁，一头连着Windows API，另一头通向浏览器宿主。没有正确的头文件和静态库，这座桥根本建不起来。

调试器附着：潜入iexplore.exe的秘密行动

IE插件不能独立运行，它是寄生在 iexplore.exe 进程里的“特工”。所以传统的F5启动方式完全失效。我们必须采取特殊手段—— 进程附加调试 。

有两种方式可以实现：

方式一：自动启动+调试

右键项目 → 属性 → 调试
设置“命令”为：

C:\Program Files\Internet Explorer\iexplore.exe

“命令参数”设为你测试页面的URL：

http://localhost/test.html

这样每次按下F5，VS就会自动拉起IE并挂上调试器。方便是方便，但有个坑：IE保护模式可能会阻止插件加载。记得去“Internet选项 → 安全”里把“启用保护模式”关掉，否则你会怀疑人生。

方式二：手动附加（更灵活）

1. 先打开IE访问任意页面
2. VS菜单 → 调试 → 附加到进程
3. 在列表里找到 iexplore.exe
4. 勾选“显示所有用户的进程”
5. 选择那个 没有标记“保护模式” 的实例
6. 调试器类型选“混合”

⚠️ 注意：一个IE可能有多个进程，通常只有一个主框架进程是非保护模式的。附错了会导致断点无效。

为了提高效率，我习惯在 DllMain(DLL_PROCESS_ATTACH) 里加个辅助函数：

#ifdef _DEBUG
void DebugBreakIfAttached()
{
    if (IsDebuggerPresent()) {
        OutputDebugString(L"[PLUGIN] Debugger attached, breaking...\n");
        __debugbreak(); // 触发断点
    }
}
#endif

这样一来，只要调试器一连上，程序就会自动暂停，让你精准定位到加载初期的状态。简直是居家旅行、排查问题必备良方！🎯

创建Win32 DLL项目：打下第一根桩

有了武器，接下来就是动手建房子。我们先来创建最基础的DLL骨架。

使用向导生成纯净项目

打开Visual Studio → 新建项目 → 动态链接库（DLL）模板（C++类别下）

取个名字，比如 IEToolBarPlugin ，然后注意两点：

• ❌ 不要勾选“预编译头”
• ❌ 不要启用SDL检查

我们要的是一个干净、透明的起点，任何自动化的东西都可能掩盖底层机制。

生成后的基本结构如下：

IEToolBarPlugin/
├── IEToolBarPlugin.cpp     // 主源文件
├── IEToolBarPlugin.h       // 头文件
├── resource.h              // 资源ID定义
├── IEToolBarPlugin.rc      // 资源脚本
└── stdafx.h/cpp            // 若启用预编译头

初始 IEToolBarPlugin.cpp 内容长这样：

#include "pch.h"
#include "IEToolBarPlugin.h"

BOOL APIENTRY DllMain(HMODULE hModule,
                      DWORD ul_reason_for_call,
                      LPVOID lpReserved)
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

现在它什么都干不了，甚至连COM都不知道是什么。我们需要让它“觉醒”。

编译选项配置：每一步都有讲究

为了让这个DLL能在IE中顺利加载，有几个关键设置必须调整到位：

类别	属性	推荐设置	说明
常规	目标文件扩展名	.dll	必须
常规	配置类型	动态库 (.dll)	确保生成DLL
C/C++ → 常规	警告等级	/W3 或 /W4	捕获潜在错误
C/C++ → 预处理器	预处理器定义	_USRDLL;IE_TOOLBAR_PLUGIN_EXPORTS	控制导出符号
链接器 → 常规	输出文件	$(OutDir)$(TargetName).dll	标准路径
链接器 → 输入	模块定义文件	IEToolBarPlugin.def （如有）	显式导出函数
链接器 → 调试	生成调试信息	是 (/DEBUG)	生成PDB
链接器 → 系统	子系统	Windows (/SUBSYSTEM:WINDOWS)	无控制台窗口

特别强调一点： 子系统必须设为 WINDOWS ，不然运行时会出现一个讨厌的黑框控制台窗口，严重影响用户体验。这不是你想看到的，对吧？😅

导出方式之争： __declspec vs .def 文件

有两种主流方式可以让外部程序调用DLL中的函数：

1. 使用 __declspec(dllexport)
2. 使用 .def 文件列出导出函数

方法一： __declspec(dllexport) —— 现代派的选择

// IEToolBarPlugin.h
#ifdef IE_TOOLBAR_PLUGIN_EXPORTS
#define PLUGIN_API extern "C" __declspec(dllexport)
#else
#define PLUGIN_API extern "C" __declspec(dllimport)
#endif

PLUGIN_API HRESULT CreateInstance(REFIID riid, void** ppv);

优点很明显：语法直观，配合宏可以轻松区分导入/导出方向。

缺点也很致命：C++名称修饰会让函数名变得面目全非（除非加 extern "C" ），而且无法指定导出序号。

方法二： .def 文件 —— 老派匠人的坚持

创建 IEToolBarPlugin.def 文件：

LIBRARY "IEToolBarPlugin"
EXPORTS
    DllGetClassObject @1
    DllCanUnloadNow @2
    DllRegisterServer @3
    DllUnregisterServer @4

然后在项目属性中指定该文件路径。

它的优势在于：

• 可指定导出序号（@1,@2…），减小DLL体积
• 不受C++名称修饰影响
• 更清晰地表达COM必需入口点

当然，维护成本高、缺少类型检查是硬伤。

对比总结表格

特性	__declspec	.def 文件
是否需要 extern “C”	是（防名称修饰）	否
支持序号导出	否	是
易于维护	高	中
编译期检查	有	无
推荐场景	普通导出函数	COM标准接口

✅ 最终建议：结合使用！

• 用 .def 文件导出COM标准函数（ DllGetClassObject 等）
• 其他内部函数使用 __declspec

这才是高手的做法 👨‍💻

模块初始化与资源管理：让DLL真正活起来

DLL的生命周期由操作系统统一调度，而一切故事的开端，都在 DllMain 函数中。

DllMain：不该被忽视的生命线

HMODULE g_hInst = nullptr;
LONG g_nLockCnt = 0;

BOOL APIENTRY DllMain(HMODULE hModule,
                      DWORD   ul_reason_for_call,
                      LPVOID  lpReserved)
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        DisableThreadLibraryCalls(hModule); // 减少通知开销
        g_hInst = hModule;
        OutputDebugString(L"DllMain: PROCESS_ATTACH\n");
        break;

    case DLL_PROCESS_DETACH:
        OutputDebugString(L"DllMain: PROCESS_DETACH\n");
        break;
    }

    return TRUE;
}

这段代码虽短，但每一行都很讲究：

• DisableThreadLibraryCalls(hModule) ：告诉系统不必为每个线程调用 DLL_THREAD_ATTACH/DETACH ，显著提升性能。
• g_hInst = hModule ：保存模块句柄，后续用于加载图标、字符串等资源。
• OutputDebugString ：用于调试跟踪，确认加载/卸载行为。

⚠️ 但是！这里有条铁律：不要在 DllMain 中做这些事！

• ❌ LoadLibrary / GetProcAddress
• ❌ CoInitialize / CoCreateInstance
• ❌ CreateWindow

原因很简单：可能导致死锁。Windows DLL加载顺序是有严格规则的，违反它轻则崩溃，重则系统不稳定。

内存泄漏检测：防止慢性自杀

IE插件长期驻留在浏览器进程中，一次微小的内存泄漏也可能日积月累变成灾难。启用CRT内存检测机制至关重要。

#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>

#ifdef _DEBUG
#define new new(_NORMAL_BLOCK, __FILE__, __LINE__)
#endif

// 在 DllMain 中添加
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

当程序退出时，CRT会自动打印未释放的内存块堆栈：

Detected memory leaks!
Dumping objects ->
{123} normal block at 0x00A02F30, 32 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD 
Object was allocated at:
    f:\dd\vctools\crt\vcstartup\heap\debug_heap.cpp(1003) : operator new
    c:\project\ietoolbarplugin\main.cpp(45) : MyFunction+10

这份报告简直就是破案神器！🕵️‍♂️

资源嵌入：自包含部署的艺术

优秀的插件应该能做到“复制即用”，不需要额外的资源文件。这就要求把图标、字符串等统统打包进DLL。

添加图标资源步骤：

1. 资源视图 → 右键 → 添加资源 → Icon → 导入 .ico 文件
2. 设置ID为 IDI_TOOLBAR_ICON
3. 在代码中加载：

HICON LoadToolbarIcon()
{
    return (HICON)LoadImage(g_hInst, MAKEINTRESOURCE(IDI_TOOLBAR_ICON),
                            IMAGE_ICON, 16, 16, LR_DEFAULTCOLOR);
}

添加字符串表：

创建字符串表资源，添加条目：

IDS_PLUGIN_NAME    "My IE Toolbar"
IDS_BUTTON_TOOLTIP "Click to activate"

加载方式：

WCHAR szName[64];
LoadStringW(g_hInst, IDS_PLUGIN_NAME, szName, 64);

这样一来，整个插件就是一个独立的DLL文件，部署起来轻松愉快～ 🎉

构建自动化：告别手动操作

大型项目离不开自动化。我们来搞一套完整的CI/CD流水线雏形。

Debug/Release差异化配置

配置项	Debug	Release
运行时库	/MDd	/MD
优化	禁用	/O2
调试信息	/Zi	/Zi （保留PDB）
预处理器定义	_DEBUG	NDEBUG
CRT断言	启用	禁用

通过属性管理器为不同配置单独设置，避免混淆。

批处理脚本：一键构建+注册

创建 build.bat ：

@echo off
set VCVARS="C:\Program Files\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat"
call %VCVARS%

msbuild IEToolBarPlugin.sln /p:Configuration=Release /p:Platform=x64
if errorlevel 1 exit /b 1

copy x64\Release\IEToolBarPlugin.dll ..\deploy\
regsvr32 /s ..\deploy\IEToolBarPlugin.dll
echo Build succeeded and registered.

以后只需要双击这个脚本，就能完成环境初始化、编译、复制与注册全过程。再也不用手忙脚乱地一个个操作了！

输出目录规范化

建议采用统一输出结构：

deploy/
├── plugin.dll
├── plugin.pdb
├── register.bat
└── unregister.bat

其中 register.bat 内容：

@echo off
regsvr32 "%~dp0plugin.dll"
pause

简单明了，连现场运维人员都能搞定。

---

至此，我们已经搭建起了一个健壮的IE插件开发环境。但这只是开始。真正的挑战在于： 如何让这个DLL变成一个能与浏览器交互、拥有UI界面、响应用户操作的完整插件 ？

答案就在下一章：COM与ATL的魔法世界。🧙‍♂️✨

COM与ATL：解开IE插件的核心密码

如果说Win32 API是砖瓦，那么COM就是钢筋混凝土。IE插件之所以能在浏览器进程中自由穿梭、操控DOM、拦截请求，靠的就是COM这套二进制接口标准。

COM的本质：不只是对象模型

COM不是类库，也不是框架，它是一种 二进制接口规范 。这意味着无论你是用VC++、VB6还是Delphi写的组件，只要遵循COM规则，就可以无缝互操作。

其核心理念有三：

1. 接口即契约 ：所有通信必须通过接口进行
2. 引用计数 ：对象自主管理生命周期
3. 语言无关 ：只要能处理vtable调用的语言都能参与

每一个IE插件本质上就是一个实现了特定接口集的COM对象。注册后通过CLSID被IE识别并实例化。

接口、GUID与注册机制原理

在COM世界里，每个接口和类都有唯一的128位标识符——GUID。

• 接口用IID（Interface ID）
• 类用CLSID（Class ID）

例如， IObjectWithSite 的IID是 {FC4801A3-2BA9-11CF-A2AE-00AA003D7352} 。当IE想要获取这个接口时，就会去注册表里找对应的DLL路径，加载之，创建对象。

典型注册项结构如下：

注册表路径	值名称	说明
HKEY_CLASSES_ROOT\CLSID\{Your-Clsid}	默认值	插件描述
HKEY_CLASSES_ROOT\CLSID\{Your-Clsid}\InprocServer32	默认值	DLL路径
ThreadingModel	“Apartment”	线程模型
Programmable	（空键）	支持脚本调用

我们可以写一个注册函数自动完成这件事：

STDAPI RegisterServer(const CLSID& clsid, 
                      const char* szFriendlyName,
                      const char* szVerIndProgID,
                      const char* szProgID)
{
    char szCLSID[MAX_PATH];
    char szModule[MAX_PATH];

    StringFromGUID2(clsid, szCLSID, sizeof(szCLSID));
    GetModuleFileNameA(_AtlBaseModule.GetModuleInstance(), szModule, MAX_PATH);

    CRegKey key;
    key.Create(HKEY_CLASSES_ROOT, "CLSID\\" + std::string(szCLSID));
    key.SetStringValue("", szFriendlyName);

    key.Create(HKEY_CLASSES_ROOT, "CLSID\\" + std::string(szCLSID) + "\\InprocServer32");
    key.SetStringValue("", szModule);
    key.SetStringValue("ThreadingModel", "Apartment");

    // ... 其他注册逻辑
    return S_OK;
}

引用计数：谁动了我的delete this？

COM对象的生命周期不由构造函数决定，而是由引用计数精确控制。

ULONG STDMETHODCALLTYPE AddRef()
{
    return InterlockedIncrement(&m_dwRef);
}

ULONG STDMETHODCALLTYPE Release()
{
    ULONG lRef = InterlockedDecrement(&m_dwRef);
    if (lRef == 0)
        delete this;
    return lRef;
}

看到 delete this 了吗？这是合法的！前提是析构函数中不再访问成员变量。

整个生命周期可以用下面的序列图表示：

sequenceDiagram
    participant Client
    participant COM_Object
    Client->>COM_Object: CoCreateInstance(CLSID, IID_PPV_ARGS(&p))
    activate COM_Object
    COM_Object-->>Client: 返回接口指针，AddRef()
    Client->>COM_Object: p->DoSomething()
    Client->>COM_Object: p->Release()
    alt 引用计数 > 0
        COM_Object-->>Client: 对象继续存活
    else 引用计数 == 0
        COM_Object->>COM_Object: delete this
        deactivate COM_Object
    end

这种机制彻底解除了内存管理的责任绑定，是COM松耦合哲学的体现。

ATL登场：把复杂留给自己，把简单交给开发者

原生COM编程太繁琐？微软早就想到了。ATL（Active Template Library）应运而生，用C++模板和宏帮你屏蔽大部分样板代码。

CComModule：模块中枢

早期ATL用 CComModule 管理整个COM模块：

CComModule _Module;

BEGIN_OBJECT_MAP(ObjectMap)
    OBJECT_ENTRY(CLSID_MyToolbar, CMyToolbar)
END_OBJECT_MAP()

extern "C" BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID)
{
    if (dwReason == DLL_PROCESS_ATTACH)
        _Module.Init(ObjectMap, hInstance);
    else if (dwReason == DLL_PROCESS_DETACH)
        _Module.Term();
    return TRUE;
}

简洁吧？对象映射、注册注销一气呵成。

CComCoClass：类厂自动生成

以前你要手写类厂实现，现在只需一行宏：

class CMyToolbar :
    public CComObjectRootEx<CComSingleThreadModel>,
    public CComCoClass<CMyToolbar, &CLSID_MyToolbar>,
    public IObjectWithSite
{
public:
    DECLARE_REGISTRY_RESOURCEID(IDR_MYTOOLBAR)

    BEGIN_COM_MAP(CMyToolbar)
        COM_INTERFACE_ENTRY(IObjectWithSite)
    END_COM_MAP()
};

CComCoClass 自动合成类厂逻辑， BEGIN_COM_MAP 构建接口查找表。高效又安全。

浏览器交互与UI停靠：让插件真正可用

现在我们终于要进入实战阶段了。怎么让插件出现在IE界面上？怎么监听页面事件？怎么注入脚本？

获取浏览器上下文：SetSite是钥匙

IObjectWithSite::SetSite 是插件与宿主建立联系的第一步。

STDMETHODIMP CToolBarPlugin::SetSite(IUnknown* pUnkSite)
{
    if (pUnkSite)
    {
        CComPtr<IServiceProvider> spServiceProvider;
        HRESULT hr = pUnkSite->QueryInterface(IID_IServiceProvider, 
                                             (void**)&spServiceProvider);
        if (SUCCEEDED(hr))
        {
            hr = spServiceProvider->QueryService(SID_SWebBrowserApp,
                                                IID_IWebBrowser2,
                                                (void**)&m_spWebBrowser);
            if (SUCCEEDED(hr) && m_spWebBrowser)
            {
                ConnectEventSink(); // 开始监听事件
            }
        }
    }
    else
    {
        DisconnectEventSink();
        m_spWebBrowser.Release();
    }

    return IObjectWithSiteImpl<CToolBarPlugin>::SetSite(pUnkSite);
}

关键点：

• 用 IServiceProvider 查询服务
• 用 SID_SWebBrowserApp 获取主浏览器对象
• 成功后立即连接事件接收器

监听页面事件：掌握最佳时机

光有浏览器对象还不够，我们需要知道什么时候页面加载完成。

class CToolBarPlugin :
    public IDispEventSimpleImpl<1, CToolBarPlugin, &DIID_DWebBrowserEvents2>
{
public:
    BEGIN_SINK_MAP(CToolBarPlugin)
        SINK_ENTRY_INFO(1, DIID_DWebBrowserEvents2, DISPID_DOCUMENTCOMPLETE, OnDocumentComplete, &OnDocCompleteInfo)
    END_SINK_MAP()

    void __stdcall OnDocumentComplete(IDispatch* pDisp, VARIANT* URL);
};

void CToolBarPlugin::ConnectEventSink()
{
    DispEventAdvise(m_spWebBrowser, &DIID_DWebBrowserEvents2);
}

void __stdcall CToolBarPlugin::OnDocumentComplete(IDispatch* pDisp, VARIANT* pURL)
{
    CComQIPtr<IWebBrowser2> spBrowser(pDisp);
    if (spBrowser)
    {
        ExecuteScriptOnPage(spBrowser); // 此时DOM已就绪
    }
}

事件绑定流程如下：

sequenceDiagram
    participant IE as Internet Explorer
    participant Plugin as CToolBarPlugin
    participant Browser as IWebBrowser2
    participant Sink as Event Sink

    IE->>Plugin: SetSite(pUnkSite)
    Plugin->>Plugin: QueryService(SID_SWebBrowserApp)
    Plugin-->>Browser: m_spWebBrowser 获取
    Plugin->>Sink: DispEventAdvise(Browser, DIID_DWebBrowserEvents2)
    loop 每次页面跳转
        Browser->>Sink: Fire DOCUMENTCOMPLETE
        Sink->>Plugin: OnDocumentComplete()
        Plugin->>Browser: get_Document(), ExecuteScript()
    end

注入JavaScript：操纵网页内容

一旦页面加载完成，我们就可以执行脚本了：

HRESULT CToolBarPlugin::ExecuteScriptOnPage(IWebBrowser2* pBrowser)
{
    CComPtr<IDispatch> spDocDisp;
    pBrowser->get_Document(&spDocDisp);

    CComQIPtr<IHTMLDocument2> spHTMLDoc(spDocDisp);
    if (!spHTMLDoc) return E_NOINTERFACE;

    CComBSTR bstrScript(L"document.getElementById('username').value = 'auto_filled';");
    EXCEPINFO excepInfo = {0};
    UINT nArgErr = 0;

    return spHTMLDoc->parentWindow()->execScript(bstrScript, L"JavaScript", nullptr);
}

注意同源策略限制哦！生产环境建议配合本地代理服务使用。

UI停靠：成为浏览器的一部分

为了让工具栏嵌入IE界面，必须实现 IDockingWindow 。

STDMETHODIMP CToolBarPlugin::GetWindow(HWND* phWnd)
{
    *phWnd = m_hWnd;
    return S_OK;
}

STDMETHODIMP CToolBarPlugin::ShowDW(BOOL fShow)
{
    ShowWindow(m_hWnd, fShow ? SW_SHOW : SW_HIDE);
    return S_OK;
}

STDMETHODIMP CToolBarPlugin::CloseDW(DWORD)
{
    DestroyWindow(m_hWnd);
    return S_OK;
}

再配合 WM_SIZE 和 WM_PAINT 消息处理，就能实现流畅的布局调整和绘制。

部署、调试与完整流程实战

最后一步，把理论变成现实。

注册表配置：让IE认出你

除了CLSID，还要归类至 CATID_Toolbar ：

key.Create(HKEY_CLASSES_ROOT, "CLSID\\{YOUR-GUID}\\Implemented Categories\\{00021493-0000-0000-C000-000000000046}");

这样才能在“查看 → 工具栏”菜单中出现。

多版本兼容性测试

IE版本	注意事项
IE8	需要数字签名
IE9	增强保护模式下可能隔离
IE10+	默认启用EPM，需管理员权限

建议用虚拟机搭建测试环境。

调试技巧大公开

• 用 DbgView 查看 OutputDebugString 输出
• 用 Application Verifier + PageHeap 检测内存越界
• 断点设在 DllMain 和 SetSite

向未来迁移的思考

随着IE停服，我们应该考虑：

• 将功能迁移到 Edge扩展
• 使用 WebView2 嵌入现代渲染引擎
• 包装为 BHO + 外部Agent服务

例如，Edge扩展也能实现类似脚本注入：

chrome.tabs.executeScript(tab.id, {
  code: 'document.body.style.backgroundColor="yellow";'
});

时代在变，但解决问题的思路不变。

---

回望整个旅程，我们从一个空DLL开始，逐步构建出一个完整的IE插件。这其中涉及的知识点繁杂而深奥，但只要你掌握了COM本质、ATL机制和调试方法，就能游刃有余地应对各种挑战。

也许有一天，IE真的会彻底消失。但这段经历教会我们的——对底层机制的理解、对系统边界的探索、对稳定性的执着追求——将永远伴随每一位开发者前行。🚀

本文还有配套的精品资源，点击获取

简介：开发浏览器插件是IT领域中提升用户浏览体验的重要技术手段。本文聚焦于利用Visual C++（VC）开发Internet Explorer（IE）的工具条插件（IE Toolbar），深入讲解如何通过COM组件模型构建可集成到IE中的功能扩展。项目以DLL形式实现，结合ATL库进行界面设计与事件处理，并通过实现IObjectWithSite、IDockingWindow等关键接口完成插件的注册与嵌入。配套源码“MotleyFool_src”提供了完整的开发参考，涵盖项目创建、UI设计、接口实现、注册机制及调试流程，帮助开发者掌握系统级浏览器扩展开发的核心技能。

本文还有配套的精品资源，点击获取