On Oct 29, 2003, at 4:12 PM, Gisle Vanem wrote:
Here's a small patch to make the plugin*.c files compile
on MingW and MSVC. filesystem.h is needed for the
p_get_datafile_path variable.
I checked in changes to do both of those yesterday.
BTW, a while ago, I asked:
On Mon, Aug 25, 2003 at 07:24:22PM +0200, Gisle Vanem wrote:
When was this true? An .exe-file can export symbols just as easily as
an
DLL can. But it AFAIK requires all exported and imported symbols be
marked
correctly. Something like:
#if defined(WIN32)
#if defined(BUILDING_PLUGIN)
#define ETR_API __declspec (dllimport)
#else
#define ETR_API __declspec (dllexport)
#endif
#else
#define ETR_API
#endif
A page at MSDN says:
Pros and Cons of Using __declspec(dllexport)
Using __declspec(dllexport) is convenient because you do not
have to worry about maintaining a .DEF file and obtaining the
decorated names of the exported functions. However, you do not
have control over the export ordinals that the compiler
generates. This method is suitable if, for example, you are
designing a DLL for use with an application that you control; if
you rebuild the DLL with new exports, you will also have to
rebuild the application.
So if you replace "DLL" with "application" and "application" with
"DLL",
is that also true?
I.e., does it mean that the plugin interface changes in a
non-binary-compatible fashion if we do something that changes the
export
ordinals for functions exported by Ethereal?
If so, could we work around that by having a .def file for the
executable image? That means we still have to have, on Windows, a list
of the functions in the plugin API; however, the list only has to give
the name and an ordinal - there's no need for the function prototype.
I.e.:
Is it the case that such a scheme would mean that plugins would
potentially have to be rebuilt for every new Ethereal binary, as the
ordinals of the functions exported from the binary to the plugins could
change?
If so, can we build the Ethereal and Tethereal binaries with a .def
file and force the ordinals to be what *we* want them to be (modulo
functions being *removed*, but if a function is removed, plugins might
have to be rebuilt *anyway*).
