title: How to allow DLLs compiled against different versions of Visual Studio in the same process to use Threading Building Blocks
body: <p>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). </p>
  
  <p>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?</p>
  
  <p>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?</p>
  
  <p>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)?</p>
  
  <p>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?</p>
  
  <p>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.</p>