requires that the dfilter code be initialized before the plugins are
added; this required us to *re*-initialize the dfilter code after
reading in all the plugins, as the plugins may themselves have added new
filterable fields - that was a bit of a mess), and make the
"Tools->Plugins" dialog box show the new-style plugins.
svn path=/trunk/; revision=2950
plugins, as the MGCP dissector uses it.
Don't set pointers to "dfilter_init()" and "dfilter_cleanup()" in that
transfer vector, as there *aren't* any pointers to them in the transfer
vector.
svn path=/trunk/; revision=2949
be loaded and their initialization routines called in right after we
call the initialization routines for built-in dissectors, but don't call
their handoff registration routines yet, and then call the handoff
registration routines right after calling the handoff registration
routines for built-in dissectors.
Do all that in "proto_init()", rather than "epan_init()".
That way, we call all dissector registration routines together, and then
call all dissector handoff registration routines together; all the
registration routines are called before any handoff registration
routines, as is required, and, as "proto_init()" is called by
"epan_init()" before "dfilter_init()" is called, all filterable fields
have been registered before "dfilter_init()" is called, and no plugins
have to call "dfilter_init()" themselves to get their fields registered.
Remove pointers to "dfilter_init()" and "dfilter_cleanup()" from the
plugin address table, as plugins shouldn't be calling them any more, and
remove calls to them from plugins.
svn path=/trunk/; revision=2940
It was the last dissector that used "old_call_dissector()", and
tvbuffifying it got rid of that, so get rid of "old_call_dissector()".
svn path=/trunk/; revision=2892
"prefs_register_module()" except that it takes a protocol index as
returned by "proto_register_protocol()" as its first argument, rather
than taking two character strings as arguments as its first two
arguments, and uses the protocol's abbreviation as the name to use for
preferences in the preferences file and the "-o" flag and uses the
protocol's short name as the name to use in the tabs in the
"Edit->Preferences" window.
svn path=/trunk/; revision=2812
involving "g_module_build_path()", rather than by checking the platform
- this should let us handle non-Windows platforms that don't use ".so"
(e.g., HP-UX).
Use G_DIR_SEPARATOR_S as the pathname separator character when
generating the pathname of the module.
svn path=/trunk/; revision=2712
declare it, and define a "BIT_SWAP" macro that uses it, in
"epan/bitswap.h".
Use that macro to bit-swap bytes in the IEEE 802.11 dissector, rather
than the macro that was used (said macro used GCCisms and didn't compile
on Windows).
Make an "init_plugin()" routine to enable a plugin and call its init
routine, and call it from "check_plugin_status()" and
"plugins_enable_cb()", rather than having very similar code in two
places; "patable" is now part of libethereal, and, at least on Windows,
attempts to refer to it from "libui" failed. Make "patable" static to
"epan/plugins.c". (This may still not work, as now "libui" is calling a
routine in "libethereal"; if that fails, perhaps it's time to get rid of
the "enable/disable plugins" stuff completely, as new-style plugins, at
least, register themselves as protocols and should be controllable from
the "Edit->Protocols" window just as built-in dissectors are.)
svn path=/trunk/; revision=2649
dissector can get a "handle" for that dissector by name and then call
that dissector through the handle.
This allows dissectors that can't be called through a port table or a
heuristic table to be called from other dissectors without directly
referring to the dissector function - dynamically-loaded modules, under
Windows, cannot directly call functions in the main program, and
non-plugin dissectors are in the main program and thus cannot be called
from plugin dissectors unless either
1) a pointer to the dissector is put in the Big Transfer Vector
or
2) some other mechanism for getting a pointer to the dissector
is provided.
This mechanism could also support registering old-style dissectors and
calling them from new-style dissectors without the new-style dissector
having to do the argument translation itself (I didn't add support for
registering old-style dissectors because I'd prefer to have people
tvbuffify their code if they have to register a dissector...).
It could also, in the future, perhaps support
disabling of protocols;
setting "pinfo->current_proto";
inside "call_dissector()" - and inside "{old_}dissector_try_port()" and
"{old_"dissector_try_heuristic()" - allowing a pile of stuff that
currently has to be done in every dissector be done by common code.
(I have some ideas about how to do this, by
having "proto_register_protocol()" take an abbreviation - of the
sort that would be put in, for example, "pinfo->current_proto" -
as an argument;
having the calls to register dissectors take an index returned
by "proto_register_protocol()" as an argument.
The abbreviation could be used elsewhere as well, e.g. in the "Decoding"
tab of the "Edit->Protocols" dialog box, and in a GUI for constructing
protocol filters. Watch this space.)
Make "dissect_sdp()" the first client of this mechanism; it's now static
to "packet-sdp.c", and all dissectors that call it - including the MGCP
plugin - now call it through a dissector handle fetched by
"find_dissector()". (Next step - see if Ethereal can now compile on
Windows as a result of this.)
svn path=/trunk/; revision=2647
"proto_item_set_len()", "proto_item_set_text()", and the preference
routines expected to be used by dissectors to the table of function
pointers handed to dissectors on platforms where dynamically-loaded
modules can't access symbols from the main program.
svn path=/trunk/; revision=2638
of function pointers handed to dissectors on platforms where
dynamically-loaded modules can't access symbols from the main program.
svn path=/trunk/; revision=2635
"plugins/Makefile.nmake" to build that plugin.
Add to the table of routines callable from plugins
"old_dissector_add()", "old_dissect_data()", and
"proto_is_protocol_enabled()", so that the Gryphon dissector can build
on Windows.
Move the includes of "plugins/plugin_api.h" and "moduleinfo.h" before
all the other includes, except for "config.h", in "plugin-mgcp.c", to
match what the Gryphon dissector does; "plugins_api.h" must be included
before any of the routines whose names it #defines in order for the
plugin to build on Windows. (It still doesn't build on Windows, as
still more routines need to be added to the table of routines callable
from plugins, but tomorrow is another day. Making libethereal a DLL may
obviate the need for that table, *if* all the routines called from a
plugin are in libethereal, as I think routines in a DLL, even a
run-time-loaded DLL, can call routines from another DLL as long as those
routines are exported from the other DLL.)
svn path=/trunk/; revision=2623
variables and a "dissector" routine, a "plugin_reg_handoff()" routine,
which will act just like the "reg_handoff()" routine of a non-plugin
dissector, registering the dissector with handoff tables.
This lets them plug into both TCP and UDP, or plug into protocols other
than TCP or UDP.
Those new-style plugin are enabled and disabled using the standard
"Edit->Protocols" mechanism (and thus should use
"OLD_CHECK_DISPLAY_AS_DATA()" or "CHECK_DISPLAY_AS_DATA()"); they don't
show up in the list of plugins, aren't enabled or disabled from that
list, and, as they don't have a filter, can't have the filter changed
from that list - instead, they should register preferences for port
numbers and the like if they should be configurable to use different
ports.
Make the Gryphon protocol a new-style plugin.
svn path=/trunk/; revision=2565
file, rather than the top-level Ethereal configuration file, check for
"inet_aton()", "inet_pton()", and "inet_ntop()". Then make its
Makefile.am include the appropriate object files if necessary.
Otherwise, they don't get built and put into libethereal, and therefore
attempts to link with anything in libethereal that uses them fail on
platforms that lack ethem, causing the build to fail.
That means a bunch of things need to be fixed to cope with libethereal
having its own "config.h" file; this means removing the include of
"config.h" from some libethereal header files. Move the definitions of
the path names used only by "resolv.c" to "resolv.c" from "resolv.h" (so
"resolv.h" doesn't need "config.h", define HAVE_PLUGINS in the configure
script (so we don't have to include it in "plugins.h" to check whether
HAVE_DLFCN_H is defined).
Unfortunately, stuff outside libethereal needs to know PLUGIN_DIR; for
now, define that in the top-level configuration file, and have Ethereal
and Tethereal pass it as an argument to "epan_init()" - that should be
cleaned up at some point.
Remove from the top-level configure script checks for things used only
in libethereal.
svn path=/trunk/; revision=2498
Guy Harris