Nmap Development mailing list archives

[nping] WINAPI becoming undefined


From: Gisle Vanem <gvanem () broadpark no>
Date: Tue, 05 Apr 2011 22:20:03 +0200

I'm struggling with building nping using MingW. All programs in the
nmap package builds fine except for nping. Somewhere in the headers the 'WINAPI' definition becomes undefined! So nping's use of ShellExecute() becomes unlinkable (the __attribute__((__stdcall__)) gets lost). I need help finding out where.

My theory is that there could be a local header in nmap that shadows for
one of the system headers. Is there a tool to detect that? But I'm not sure since the dependencies (generated using gcc -MM $(CFLAGS)) for winfix.cc seems correct.

Running "gcc -E -v $(CFLAGS) winfix.cc" gives me this. First the search list output:

#include "..." search starts here:
#include <...> search starts here:
.
..
../nbase
../nsock/include
../mswin32
../libpcre
../libdnet-stripped/include
../liblua
g:/MingW32/src/zlib-1.2.3
g:/MingW32/src/inet/libpcap
g:/MingW32/src/inet/libpcap/WinPcap/Include
g:/MingW32/src/inet/OpenSSL-1.1.0/outinc
g:/MingW32/include
g:\mingw32\bin\../lib/gcc/mingw32/4.5.0/include/c++
g:\mingw32\bin\../lib/gcc/mingw32/4.5.0/include/c++/mingw32
g:\mingw32\bin\../lib/gcc/mingw32/4.5.0/include/c++/backward
g:\mingw32\bin\../lib/gcc/mingw32/4.5.0/include
g:\mingw32\bin\../lib/gcc/mingw32/4.5.0/include-fixed
End of search list.

Seems okay to me; it reflects my CFLAGS (except the "g:\mingw32\bin\.."
part off-course). But the preprocessed output contains this:

 # 290 "g:/MingW32/include/shellapi.h" 2 3
 ...
 HINSTANCE ShellExecuteA(HWND,LPCSTR,LPCSTR,LPCSTR,LPCSTR,INT);

I.e. the WINAPI decoration gets dropped! I also noticed that MingW's <shellapi.h> doesn't include any <windef.h>. Hence <shellapi.h> isn't atomic. Could that be part of the problem? Or is it assumed that <shellapi.h> is included after or inside <windows.h> (if WIN32_LEAN_AND_MEAN isn't defined)?

As a test I reordered and changed nping/winfix.cc headers a bit:
 #include <windef.h>   /* could use <windows.h> instead */
 #include <shellapi.h>
 #include <winclude.h>
 #include <sys/timeb.h>

Now everything is fine and dandy (nping links to ShellExecuteA@24). And I can
live with that, except I'd like to find the root of the original problem (prior to the header reordering). There must be something fishy in the nmap headers IMHO.
Anybody else built nping with MingW?

Last note: A good rule of thumb should be that local headers like <winclude.h>
should *always* be included after system headers like <shellapi.h>. It's easier to
point the finger at a problem with "#undef"-ing etc. with such a rule. nping breaks
that rule.
--gv
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


Current thread: