> > I can see version hell on the horizon.... :/ > Would it be wise to add the compiler version to the plugin version > resource? If time permits I'll start looking into it tonight. >
sort of... It's like the problem with our current plugin mechanism in general, a plugin build for a different Wireshark version may or may not run. Basically it's up to the plugin developer/user to make sure that a specific plugin works with the Wireshark version (and now compiler version as well) in use. Fortunately, if the plugin is cleanly implemented - doesn't hand over or get file handles (and alike C-runtime resources) from other parts / plugins of Wireshark, this plugin should work well with Wireshark versions compiled with a different compiler version. In any case, the plugin developer is responsible to provide the proper C runtime dll (e.g. msvcr80.dll in this example) along with his plugin. I really don't tend to install all possible msvcr*.dll versions (7.0, 7.1, 8.0, 9.0) together with the installer - just as a precaution that a plugin developer might need to use it. So the question is not how to detect such a "version conflict", but more of what to actually do in that case! Do we want to warn the user in this case "you are using a plugin ..." or even disallow the usage of the plugin, although it *might* work perfectly? Regards, ULFL P.S: The only problematic C runtime resource we use seems to be file handles, and this - at least - can be documented to be carefully used in plugins. _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066 _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
