Hi all, I was just recently debugging an issue related to Arnold's and Fury's usage of the OpenImageIO.dll library that I think I should explain so that it can possibly be avoided through a design change in the future.
Because OpenImageIO is a constantly advancing open source project, different OpenImageIO.dll included with various software packages can have different API signatures, all of which are slightly incompatible with each other. This normally wouldn't be an issue, but Windows uses a single DLL namespace for each processes. This means that if one plugin in Softimage, say plugin "A", loads one version of OpenImageIO.dll, if another Softimage plugin, say plugin "B", attempts to load another OpenImageIO.dll at a later time (based simply on the order Softimage decides to load all of its installed plugins) that is a different version (different API) that the DLL loaded by plugin "A", the second plugin will fail to load because Windows thinks both DLLs should actually be equivalent because they have the same name even when they have different APIs. This is a real risk with OpenImageIO because the API is often changing with each release (or at least it has been) and it is compiled by default as an DLL who name remains exactly the same across all these changes. As OpenImage becomes more popular and if its API keeps changing, these types of conflicts will become more common. It might actually become really problematic if Softimage (or Maya) ever decided to include a version of OpenImageIO.dll in its default installation as they would likely pick a version much older than the one included in the rapidly updating Arnold packages, but then Arnold would not be able to access the newest features offered by OpenImageIO. Of course everyone can start to compile OpenImageIO.dll with a unique name, but there is a simplier solution. I think that if the OpenImage DLL name had a version (major and minor) in it (as Boost's and Microsoft's runtime libraries do) that would address things to some extent and it would be my recommendation to the OpenImageIO guys to do this. But for us (Exocortex) this isn't an immediate necessity as we are going down the custom OpenImageIO.dll name for the time being to avoid these issues. -- Best regards, Ben Houston Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom http://www.exocortex.com _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
