38 lines
1.4 KiB
Plaintext
38 lines
1.4 KiB
Plaintext
README.interface
|
|
|
|
The following will export addresses from ethereal to the plugins. You
|
|
will have to do this, e.g. if you want to use a function of ethereal inside
|
|
your plugin.
|
|
If you need it the other way round (e.g. use symbols of your plugin inside of
|
|
ethereal's gtk part), you only have to edit libethereal.def and nothing more.
|
|
(XXX - is this libethereal.def description correct?)
|
|
|
|
|
|
When developing a plugin in the Win32 world, it is nessecary
|
|
to explicitly export addresses from the main process to the
|
|
plugin. ethereal does have a mechanism for this, and it uses
|
|
the file 'plugin_api_list.c' to list declarations for everything
|
|
that needs to be exported.
|
|
|
|
The build process of ethereal needs this list in 5 different forms.
|
|
|
|
These are generated by a Python script and saved in the X* files
|
|
in this directory.
|
|
|
|
I do not have a real C parser in Python to read the input file...,
|
|
so I have used 'gcc -aux-info xyzzy ...' to clean up any formatting
|
|
preferences in the input file and create the file named 'xyzzy'
|
|
that contains a neatly formatted list of declarations. This list
|
|
can be parsed with a regular expression to extract the required
|
|
info.
|
|
|
|
Use the following procedure to update the symbols:
|
|
|
|
edit the plugin_api_list.c file
|
|
nmake -f Makefile.nmake xyzzy
|
|
nmake -f Makefile.nmake
|
|
|
|
The 'xyzzy' makefile target is the only target that depends on gcc.
|
|
This can be done on a Unix machine or you can use cygwin gcc.
|
|
|