The protocol has a simple addition to provide the InService and
OutOfService notification for a MTPL2 link inside the protocol. This
patch adds these types to the type field, stops handing empty packages
to the MTPL3 dissector and fills out the COL_INFO with the type of
the packet.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5706

Just for fun, see whether using __declspec(noreturn) on the exception
routines is sufficient to convince the Visual Studio code analyzer that
REPORT_DISSECTOR_BUG() never returns. (That would probably require that
abort() be tagged with __declspec(noreturn); let's hope Microsoft did
the right thing there.)

Apparently, if the argument to the cd command in an nmake file contains
spaces, it needs to be quoted, the fact that, if the argument to a cd
command typed at cmd.exe contains spaces, it *doesn't* need to be quoted
nonwithstanding.

Don't allocate a bunch of memory on the stack for strings that will be
fed to col_append_fstr; columns have a maximum length of 240 characters
(ITEM_LABEL_LENGTH). Make sure our column text is properly formatted.

Use "XXX != NULL" rather than "XXX" to test for a null pointer; either
I'm missing something or the MSVC++ code analyzer doesn't realize that
in

if (XXX)
dereference XXX

will not dereference XXX if it's null - maybe "if (XXX != NULL)" will do
the trick (if so, the code analyzer is buggy, because "if (XXX !=
NULL)", "if (XXX != 0)", and "if (XXX)" mean the exact same thing if XXX
is a pointer-valued expression, really, truly, even if a null pointer
isn't represented as all zero bits or if it's wider than an int).

Squelch a warning from the MSVC++ static analyzer (it's worried that
GetModuleHandle() could return a null pointer, which is possible,
although if it returns one when handed "kernel32.dll", you have bigger
problems...).

Put the "MCS known information" field into the protocol tree; yes, it's
somewhat redundant, as items aren't displayed if they're not known, but
it can make it a little clearer to people who aren't familiar with the
gory details of radiotap (which people just looking at network traffic
might not be).

The lack of _WITH_PHDR in WTAP_ENCAP_BLUETOOTH_H4 means there's no
pseudo-header, and hence there's no direction indication. Don't set
pinfo->p2p_dir for it. Use WTAP_ENCAP_BLUETOOTH_H4_WITH_PHDR, not
WTAP_ENCAP_BLUETOOTH_H4, for capture files where we have the direction.

Don't assume pinfo->p2p_dir is either P2P_DIR_SENT or P2P_DIR_RECV when
setting the info column in various Bluetooth dissectors; it might be
unknown.

In the HCI H4 dissector, put the direction into the info column
regardless of whether we have a type match or not; the dissectors for
HCI packet types appear to assume it's been set (as they put a blank at
the beginning of the stuff they append to the direction).

Add a command line argument for the configure script of "--with-gtk3" to
attempt to compile against GTK+ 3.0 (which can be installed at the same
time as GTK+ 2.0). Also place a copy of the autoconf macro for finding
GTK+ 3.0 in the aclocal-fallback directory taken from the GTK+ 3.0
distribution.