add a config.nmake option to control whether to build
libethereal.dll or not;
remove "./wiretap" from PATH to prevent problems due to
wrongly-loaded files;
build dissector.lib with MSVC;
move "print.c" and "ps.c" to the dissector helpers, as "print.c"
imports variables from packet-frame.c and packet-data.c, which
are in libethereal;
move "g711.c" out of the dissector helpers, as they're used only
by Ethereal in a tap, not in Tethereal or in any dissector;
add a .def file for libethereal;
arrange to declare global variables exported from libethereal
with "__declspec(dllimport)" when building programs that import
those variables;
update the NSIS installer.
Make the "configure" script define ETH_VAR_IMPORT as "extern".
svn path=/trunk/; revision=10834
used to construct the "Edit->Preferences" dialog box; this includes the
ability to register a "subtree" for preferences. Instead of
special-casing protocol preferences, have a subtree "Protocols" for
protocol preferences.
svn path=/trunk/; revision=6808
if a dissector had preferences at one point but no longer does, it can
register that fact, so that the old preferences in the preference file
are silently ignored.
Use that mechanism in the NCP dissector.
svn path=/trunk/; revision=5446
obsolete; we silently ignore attempts to set those in a preferences
file, so that we don't spam the user with error messages caused by them
having saved preferences in an earlier release that contained those
preferences.
Make the Diameter and iSCSI dissectors register obsolete preferences.
Crash if some code tries to register a preferences module with a name
that contains something other than lower-case ASCII letters, numbers, or
underscores, or that has already been registered, or if some code tries
to register a preference with a name that contains something other than
lower-case ASCII letters, numbers, underscores, or periods, or that has
already been registered, so that we don't put code like that in a
release and have to shovel code into "prefs.c" to fix it up later. (The
problem with multiple modules or preferences with the same name should
be obvious; the problem with names with blanks, or upper-case letters,
or punctuation, is that they're a pain to type on the command line.)
svn path=/trunk/; revision=4148
a word to use in the progress dialog, and a flag indicating whether the
display filter is to be reevaluated or not, and:
have "colorize_packet()" call that routine with "Colorizing" and
FALSE as those arguments;
have the filtering code call that routine with "Filtering" and
TRUE as those arguments;
add an exported routine to call that routine with "Reprocessing"
and TRUE as those arguments, to use to re-generate the packet
list and to re-filter the packets if a protocol preference has
been changed.
Keep track of whether preferences are changed from their initial value
by a preferences file or a command-line option, or from their previous
value by the "Preferences" dialog box; have "prefs_apply_all()" only
call the "apply" callback for a module if they have.
Call "prefs_apply_all()" after the command-line arguments have been
parsed and after "OK" has been clicked in the "Preferences" dialog box,
to notify modules of preference changes if they've registered a callback
for that.
After "OK" has been clicked in the "Preferences" dialog box, if any
preferences have changed, call the reprocessing routine, as the summary
line for some frames and/or the current display filter's value when
applied to some frames may have changed as a result of a preference
change. Do the same after "OK" or "Apply" has been clicked in the
"Display Options" dialog box (as it controls a protocol preferences
item.
svn path=/trunk/; revision=2126
same directory as the "manuf" file ("/etc" or "/usr/local/etc", most
likely).
Add a mechanism to allow modules (e.g., dissectors) to register
preference values, which:
can be put into the global or the user's preference file;
can be set from the command line, with arguments to the "-o"
flag;
can be set from tabs in the "Preferences" dialog box.
Use that mechanism to register the "Decode IPv4 TOS field as DiffServ
field" variable for IP as a preference.
Stuff that still needs to be done:
documenting the API for registering preferences;
documenting the "-o" values in the man page (probably needs a
flag similar to "-G", and a Perl script to turn the output into
documentation as is done with the list of field);
handling error checking for numeric values (range checking,
making sure that if the user changes the variable from the GUI
they change it to a valid numeric value);
using the callbacks to, for example, update the display when
preferences are changed (could be expensive);
panic if the user specifies a numeric value with a base other
than 10, 8, or 16.
We may also want to clean up the existing wired-in preferences not to
take effect the instant you tweak the widget, and to add an "Apply"
button to the "Preferences" dialog.
svn path=/trunk/; revision=2117
Guy Harris