* Bumped target windows version to 6.0.0 (Vista).
* Use WRL COM pointers to manage some COM-like objects.
* Cleaned up logging in DirectSound module.
* Cleaned up includes in Windows input modules.
* Switched to Common Item Dialogs in Windows debugger.
* Replaced disabled code that never really worked with a TODO comment.
(nw) The pcap.h header itself has the problematic original BSD license,
including the obnoxious advertising clause. Using tap/tun networking on
Windows provides a much better experience, so the extra setup is worth
it. This patch also allows you to enable pcap on platforms where it's
disabled by default with USE_PCAP=1 if you really want to use it.
* taptun: add support for Windows
Looking for feedback only at this point, because it's the first time I've attempted any OSD stuff - be gentle.
This extends the existing taptun OSD module to support Windows through the TAP-Windows6 driver (https://github.com/OpenVPN/tap-windows6).
* TAP-Windows6 is GPLv2, however only the header file is required in MAME, and the driver itself is entirely optional.
* I've tried to minimise the size of the diff, rather than completely separate the Windows/non-Windows implementations - not sure which is preferable in this case.
* The license file has Mac(?) line-endings - unsure if they should be normalized or used verbatim.
* Uncertain about the non-Windows case (or the Windows SDL case) - existing code uses __linux__, but I'm not clear on how that works with OSX, for example?
* I can't claim this actually "works" yet, because I don't know enough to configure the tap end of it properly to get networking doing something useful, but I will get there and correct anything necessary in a subsequent real PR.
* minor fixes/improvements (nw)
* Use Unicode Windows APIs, and UTF-8 for MAME
* Deal with unterminated registry string values
* Cancel any pending I/O in destructor
Specifically, this creates a call osd_get_command_line() that returns UTF-8 command line arguments as std::vector<std::string>. On non-Windows platforms, this does nothing more than build the vector. On Windows, this invokes GetCommandLineW() and CommandLineToArgvW(). This also attempts to unwind usage of wmain()/_tmain() on Windows, which is not standard.
Related to this, this fixes a bug in Imgtool; specifically, non-7 bit ASCII was not being handled correctly in Windows.
This is really an admission that the way that Windows handles Unicode and command line arguments sucks, and it is my belief that having a wmain() or _tmain() declaration specific for Windows is a worse solution. C'est la vie.
I'm very open to the idea that src/osd/osdcore.[cpp|h] is not the best place to do this. Let me know if I should move it.
differently with different OSDs
Switch back to building for all OSDs in common directory
Move more OSD-specific stuff into OSD scripts
It still isn't completely safe to be building all OSD into same directory
Common OSD "module" files, e.g. debuggers and renderers, build with
different options for each OSD. It works at the moment, but you will end
up with slightly different executables depending on the order you build
OSDs.
