ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Win32: Visual Studio Express as default?

From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Tue, 23 Jan 2007 21:13:04 +0100 (CET)
Hi,

Well, in a perfect world this scheme would work. Unfortunately.....
So how do we help a user with an 'inperfect' plugin developer?
Could the whole range of runtime DLL's help? I guess not, mixing runtimes
doesn't sound like a plan. Check DLL dependancies? Could help if we can
detect a mismatch and popup a warning. The least we can do is help
discovery of a mismatch.

Thanx,
Jaap

On Tue, 23 Jan 2007, Ulf Lamping wrote:

> >
> > 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@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>