В моем приложении DirectShow у меня есть сторонняя DLL (32-битный фильтр DirectShow), у которого нет источника для этих ссылок на 32-битную версию Windows Intel Threading Building Blocks (tbb.dll).
Если я хочу использовать Threading Building Blocks в моей собственной DLL в том же процессе (например, в другом 32-битном фильтре DirectShow), это заставляет меня использовать ту же версию Visual Studio, которую использовал автор этой сторонней DLL?
РЕДАКТИРОВАТЬ - Я понял, что независимая от версии библиотека _mt, вероятно, является лучшей для использования в этом сценарии. Что произойдет, если сторонние поставщики не создали для этой _mt dll?
В моей собственной установке потоковых строительных блоков я замечаю, что существуют разные версии tbb.dll для разных версий Visual Studio - 2005, 2008, 2010 и 'MT' (пока не уверен, что это). Очевидная причина этого заключается в том, что разные версии tbb.dll связаны с разными версиями библиотек DLL библиотеки времени выполнения Visual Studio. Можно ли сказать, какая версия tbb.dll требуется для проверки, или мне нужно поискать строки в двоичном файле, указывающие на используемую версию компилятора (сторонняя DLL-библиотека, по-видимому, статически связывает среды выполнения Visual Studio)?
Насколько я могу судить, tbb.dll не использует манифесты и параллельное управление версиями и имеет одно и то же имя для разных версий компилятора. Последним средством было бы переименовать различные tbb.dll и взломать библиотеку импорта или импорта, чтобы ссылаться на переименованные библиотеки, но я бы действительно предпочел этого избежать. Есть ли чистый способ перенаправить импорт с помощью параметров компоновщика?
Поскольку эти библиотеки DLL хорошо работают, фильтры DirectShow не будут передавать между ними среду выполнения Visual Studio или объекты TBB, что, несомненно, будет опасно. Их взаимодействие будет ограничено вызовами друг друга через стандартные вызовы COM DirectShow.