> > Cool. Do you have patches to "Makefile.am" and "Makefile.nmake" as
> > well?
>
> They were in the original patch. Nothing in them changed to build under
> Windows.
I dug that, and some of the other files, from various mail messages you
sent; hopefully, I got all the right pieces assembled.
> Plus, if you run nmake from Dos (CMD.exe), where it can't find sed, it
> barfs and creates partial config files that don't work right. It's really
> strange. (The worst part is, ./configure does *almost* work. I took that
> path initially, and ran into many problems. Eventually it would be really
> cool to build it completely under cygwin with gcc)
>
> I had to keep going back and forth from cygwin to CMD to get
> things right.
Odd - I do all my builds under Bash from Cygwin, not from the DOS shell.
What things did you have to do under the DOS shell, other than run
"cleanbld.bat"?
(Perhaps we should add a "distclean" entry to the "Makefile.nmake"
files, so that
nmake -f makefile.nmake distclean
does what
make distclean
does on UNIX, namely get rid of all files that didn't come as part of
the source disribution, including the "config.h" files.)
> (And, then, I had to move all the DLLs somewhere in the path, and it
> actually worked!
Yes, on Windows Ethereal considers the "installation directory" to be
the directory in which the Ethereal binary resides; this means it looks
in a "plugins\{plugin version}" (where "{plugin version}" is the current
version number for plugins) subdirectory of that directory for plugins.
If you're running Ethereal from the build directory, you should create a
"{plugin version}" subdirectory of the "plugins" source directory and
move or copy the plugin DLLs there.
> Although, the DNS lookups seemed MUCH slower than under linux)
DNS lookups, or host name lookups?
Somebody suggested a while ago on one of the Ethereal mailing lists that
IP address to host name lookups in Windows will, if the DNS lookup fails
to find a host name, do a NetBIOS-over-TCP host name lookup. A
NetBIOS-over-TCP host name lookup consists of sending a NetBIOS-over-TCP
Name Service "NODE STATUS REQUEST" message to the IP address being
looked up, and waiting for a "NODE STATUS RESPONSE" message to come back
from that host, giving its NetBIOS host name.
If the host in question isn't running NetBIOS-over-TCP software - which
UNIX boxes not running Samba or some other SMB server probably aren't
doing - it won't send out a NODE STATUS RESPONSE message, meaning the
routine ("gethostbyaddr()", or whatever) doing the lookup may have to
wait a while for a timeout before giving up and saying "sorry, I don't
know the host name for this IP address".
I.e., if *successful* host name lookups don't seem slower on Windows
than UNIX, but *unsuccessful* ones do, that might just be due to
unsuccessful DNS lookups on Windows causing a NetBIOS-over-TCP lookup to
be done, and, if unsuccessful, those take a while to fail.
In addition, there's code in "host_name_lookup()" in epan/resolv.c to
impose a 2-second timeout on host name lookups, so even slow DNS lookups
will get aborted after 2 seconds; however, that code depends on the UNIX
SIGALRM signal and "alarm()" call working, so it isn't used on Windows.
Then again, I'm not sure I see something enabling it on UNIX, either,
which suggests that slow DNS or NIS host name lookups won't get timed
out after 2 seconds even on UNIX. I think we *used* to enable it, but
I'm not sure what happened to that.
