如何允许在同一进程中针对不同版本的 Visual Studio 编译的 DLL 使用线程构建块
在我的 DirectShow 应用程序中，我有一个第三方 DLL（32 位 DirectShow 过滤器），但我没有针对 32 位 Windows 版本的英特尔线程构建模块 (tbb.dll) 的链接的源代码。
如果我想在同一进程（例如另一个 32 位 DirectShow 过滤器）中使用我自己的 DLL 中的线程构建块，这是否会强制我使用与该第三方 DLL 的作者使用的同一版本的 Visual Studio？
编辑 - 我意识到版本无关的 _mt 库可能是在这种情况下使用的最佳库。如果第三方供应商没有为此 _mt dll 构建，会发生什么情况？
在我自己的线程构建块安装中，我注意到不同版本的 Visual Studio - 2005、2008、2010 和“MT”（尚不确定是什么）有不同版本的 tbb.dll。造成这种情况的一个明显原因是不同版本的 tbb.dll 链接到不同版本的 Visual Studio 运行时库 DLL。是否可以通过检查来判断需要哪个版本的 tbb.dll，或者我是否必须在二进制文件中寻找指示所使用的编译器版本的字符串（第三方 DLL 似乎静态链接 Visual Studio 运行时）？
据我所知 tbb.dll 不使用清单和并排版本控制，并且为不同的编译器版本赋予相同的名称。最后的手段是重命名不同的 tbb.dll 并破解导入库或导入以引用重命名的 dll，但我真的宁愿避免这种情况。有没有一种干净的方法可以使用链接器选项重定向导入？
由于这些 DLL 是行为良好的 DirectShow 过滤器，因此它们不会在它们之间传递 Visual Studio 运行时或 TBB 对象，这显然是危险的。他们的交互将仅限于通过标准 COM DirectShow 调用相互调用。
In my DirectShow application I have a third party DLL (a 32bit DirectShow filter) that I don't have source for that links against the 32bit Windows version of Intel Threading Building Blocks (tbb.dll).
If I want to use Threading Building Blocks in my own DLL in the same process (e.g. another 32bit DirectShow filter) does this force me to use the same version of Visual Studio that the author of this third party DLL used?
EDIT - I've realised that the version independent _mt library is probably the best one to use in this scenario. What happens if third party vendors haven't built for this _mt dll?
In my own Threading Building blocks installation I notice that there are different versions of tbb.dll for different versions of Visual Studio - 2005, 2008, 2010 and 'MT' (not sure what that is yet). One obvious reason for this is that the different versions of tbb.dll link against different versions of the Visual Studio runtime library DLLs. Is it possible to tell which version of tbb.dll is required by inspection or do I have to grub around looking for strings in the binary indicating the compiler version used (the third party DLL appears to be linking the visual studio runtimes statically)?
As far as I can tell tbb.dll doesn't use manifests and side by side versioning and is given the same name for different compiler versions. A last resort would be to rename the different tbb.dlls and hack the import library or imports to reference the renamed dlls but I'd really rather avoid this. Is there a clean way to redirect the imports with linker options?
As these DLLs are well behaved DirectShow filters they won't be passing Visual Studio runtime or TBB objects between them which would clearly be dangerous. Their interaction will be limited to calling each other via standard COM DirectShow calls.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您没有使用 TBB，问题仅与 Visual Studio 版本有关，那么您不必担心：Visual C++ Runtime DLL 在不同版本中具有不同的名称，例如
MSVCR70.DLL、MSVCR90.DLL 等。而且，正如您已经发现的，/MT 开关将编译/链接运行时的静态版本，并将这些内容嵌入到您的 DLL 中，而不必担心与对等 DLL 共享正确的 DLL。If you are not using TBB, the question is only about Visual Studio versions, then you don't have to worry: Visual C++ Runtime DLLs have different names across versions, e.g.
MSVCR70.DLL,MSVCR90.DLLetc. And, as you already discovered, /MT switch will compile/link a static version of runtime and will embed the stuff into your DLL without having to worry about sharing right DLL with a peer DLL.