Windows (COM） API 的行为不同，没有特定的库

Windows (COM) API behaving differently w/o specific library

本文关键字：COM API Windows      更新时间：2023-10-16

似乎WindowsAPI的行为有所不同，具体取决于我是否在特定库中链接。不幸的是，这是一个相当大的库，很难追踪这个问题，而且我不知道从哪里开始。

我可以为多个 API 重现此行为。例如，我正在使用基于 COM 的外壳 API 来确定特定文件扩展名的"打开方式"应用程序。

CComPtr<IEnumAssocHandlers> enumerator;
HRESULT hr = SHAssocEnumHandlers(L".jpg", ASSOC_FILTER_RECOMMENDED, &enumerator);
for (CComPtr<IAssocHandler> handler; enumerator->Next(1, &handler, nullptr) == S_OK; handler.Release()) {
CComHeapPtr<wchar_t> wAppName;
handler->GetName(&wAppName);
std::wcout << std::wstring(wAppName) << std::endl;
}

这在不执行任何其他操作的测试应用程序中完美运行。如果我链接到所述库，它将停止工作，而不是 UWP 应用程序条目，它只会打印TWINUI。
实际上打开应用程序然后使用IAssocHandler::Invoke的行为也有所不同，并且在Adobe Photoshop的情况下，它会令人惊讶地将用户从Adobe帐户中注销(这始终是可复制的 - 也许由于不同的上下文而开始发挥作用的一些许可证保护？
我过去遇到的另一个示例是WIC(Windows映像组件(API，也是基于COM的，它返回了有关编解码器不可用的错误(在最小测试中可用(。

所以问题是：是否有编译器标志或宏可能导致这些问题？(例如 WinSDK 版本控制(
我还能寻找什么？

提前亲切的问候和感谢

事实证明，加载OpenBLAS库导致了这个问题。它甚至可以通过一个最小的例子来重现：

// code in the original post --> works
LoadLibraryA("libopenblas.dll");
// not reproducible with LoadLibraryExA("libopenblas", NULL, DONT_RESOLVE_DLL_REFERENCES);
// to avoid calling DllMain
// code in the original post --> doesn't work

因此，OpenBLAS库中的某些内容似乎破坏了Windows API。令人惊讶的是，删除库还修复了我们过去无法解决的一系列其他问题，乍一看似乎无关紧要。

我们使用一个相当旧的版本(0.2.9;DYNAMIC_ARCH已启用(，因此可能会在更高版本中修复，但由于我们根本不需要 OpenBLAS，所以我还没有尝试过。

相关文章：