>
> 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
