在这种情况下,我的动态加载的 DLL 由 Windows 资源管理器加载,以便将新的属性表(新选项卡)添加到文件/文件夹属性页面。
一个简单的例子是StrmExt.dll(下载源)。在此示例中(由 Microsoft 提供的源代码),DLL 不使用线程本地存储 (TLS),因此在同时加载多个属性页时会导致严重问题。
在查看源代码后,DLL 需要一个基于线程的变量(文件的文件路径)......
static TCHAR g_szFile[MAX_PATH];
将这一行代码更改为:
_declspec (thread) TCHAR g_szFile[MAX_PATH];
... 使 DLL 能够支持多个线程,从而支持属性表的多个实例。但是,我知道只有 Windows Vista 和更新版本才支持此更改(在 Windows 7 上的测试非常积极)。例如,XP 不支持动态加载的库...而且已知会导致应用程序崩溃。(见最后一段)。
为了在 XP 上运行,我不能使用这个声明。我怀疑我需要从以下方面增强他们的 DLL 入口点:
extern "C"
BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID /*lpReserved*/)
{
if (dwReason == DLL_PROCESS_ATTACH)
{
_Module.Init(ObjectMap, hInstance, &LIBID_STRMEXTLib);
DisableThreadLibraryCalls(hInstance);
}
else if (dwReason == DLL_PROCESS_DETACH)
_Module.Term();
return TRUE; // ok
}
......像这样......如前所述here
struct ThreadData {
static TCHAR g_szFile[MAX_PATH];
};
...
DWORD g_dwThreadIndex;
extern "C" BOOL WINAPI DllMain(HINSTANCE hInstance,
DWORD dwReason, LPVOID /*pReserved*/)
{
ThreadData* pData;
switch (dwReason) {
case DLL_PROCESS_ATTACH:
g_dwThreadIndex = ::TlsAlloc();
if (g_dwThreadIndex == TLS_OUT_OF_INDEXES)
return FALSE;
// execute the DLL_THREAD_ATTACH code
case DLL_THREAD_ATTACH:
// allocate memory for this thread
pData = (ThreadData*) ::LocalAlloc(LPTR, sizeof(ThreadData));
if (pData == 0)
return FALSE;
::TlsSetValue(g_dwThreadIndex, (LPVOID) pData);
break;
case DLL_THREAD_DETACH:
// release memory for this thread
pData = (ThreadData*) ::TlsGetValue(g_dwThreadIndex);
if (pData != 0)
::LocalFree((HLOCAL) pData);
break;
case DLL_PROCESS_DETACH:
// release memory for this thread
pData = (ThreadData*) ::TlsGetValue(g_dwThreadIndex);
if (pData != 0)
::LocalFree((HLOCAL) pData);
// release the TLS index
::TlsFree(g_dwThreadIndex);
break;
}
return TRUE;
}
无论我创建 1 个还是 2 个线程,这在第一次加载 DLL 期间都可以正常工作。释放 DLL 后,资源管理器在下次加载库时崩溃。
我有什么误解?我注意到原始开发人员在 DLL 进程附加通知时故意禁用线程通知。为什么?
DisableThreadLibraryCalls(hInstance);