> I think my problem was that I had already built under unix, then I did a
> make distclean (I think . . . perhaps I did a make clean . . that could
> have been my problem), and copied it over for my Windows work.
That could've been it - "make distclean" got rid of the "config.h" files
here.
> Also, isn't the default nmake makefile
> named Makefile.mak? Why not rename makefile.nmake to Makefile.mak so that
> you can run nmake without arguments?
If that's the default, that sounds reasonable to me. Gilbert, any
reason to have it "Makefile.nmake" rather than "Makefile.mak"?
> > DNS lookups, or host name lookups?
> Host name lookups (But, it did hit DNS to get them)
...but may also have hit NetBIOS-over-TCP, as well.
> > 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.
>
> Yeuch. Thanks again, Bill.
Well, to be fair, NetBIOS was cooked up at a time when somebody could
conceivably have thought that TCP/IP was too much to put on a desktop PC
(although I think there may have been TCP/IP stacks small enough that
perhaps it wasn't), and so they put SMB atop NetBIOS, and so maybe they
were stuck with NetBIOS-over-TCP...
...but they *could*, I suspect, have put a damn reverse lookup op into
the NetBIOS Name Service protocol, to use if you're running with a WINS
server, and maybe even, if you're not using a WINS server, have it as a
broadcast request, just as forward lookups are broadcast requests if you
have no WINS server (it's already somewhat broadcast-heavy, I suspect
that wouldn't have made matters much worse).
The list of contributors to the NetBIOS-over-TCP spec, at the end of RFC
1001 and 1002, has a bunch of Internet Old-Timers on it, though, so
maybe I'm missing something and there *is* a good reason not to have a
reverse lookup op. Or maybe it's just that the NetBIOS API didn't have
a reverse lookup op, nor did it have any operations that needed one, so
they didn't bother putting the request into the protocol.
Oh, well, what's done is done; the need for NetBIOS will probably
diminish over time (SMB no longer requires it - DNS can be used, and you
can use port 445 for direct CIFS-over-TCP, and a bunch of the other
stuff that uses the UDP NetBIOS services is, I think, migrating to stuff
such as Active Directory), so eventually that particular problem may go
away.
> I was thinking the other day about writing something like that. One of the
> threads on my diameter server got stuck in a gethostbyaddr() call. But, since
> I'm using threads, signals aren't the best way to do things. I'm thinking
> about writing a little resolver class that has timeouts built in (by spawning
> a thread to do the lookup, and waiting for it to finish for a while, then
> killing it.) But, that another beast entirely.
I assume that's on UNIX, not Windows; Winsock has, I think, an
asynchronous name lookup routine. I think they've been proposed for
UNIX, but I don't know if any have been implemented.
The Cheesy Hack that the old NetCache software used on UNIX boxes was to
have a child process (or maybe it was a pool of child processes) to
which name lookup requests were sent over a pipe; it'd do the lookup and
send a reply over the pipe. The main "select()" loop could select on
various file descriptors, including the pipe to the child process (or
the pipes to the child processes).
