The only thing a shutdown logic would do is to clean up the very resources the OS cleans up anyway when interrupting the process. So I just don't see the point in the complexity of a signal handler (and SetConsoleCtrlHandler on Windows).
Interestingly libserialport doesn't complain about any weird value. So there's nothing to validate.
Surprisingly Windows doesn't complain about any weird value! So even the sp_set_config() succeeds!
So far up to two ports with the substring "usbserial" in their name were used. This was pretty platform specific and didn't allow to use non-USB ports at all.
Now if the -p option is given its value is used as substring as "usbserial" was used before. However if no -p option is given than up to two USB-backed ports are used.
On everything but Windows building xHDServer is so trivial that everything more than a minimal Makefile is inappropriate.
On Windows requiring an additional tool (like e.g. CMake) is just another obstacle. However, GNUmake comes with Mingw-w64.
In order to optimize the user experience it is desirable to build with a static variant of libserialport. However, doing so requires on Windows in general import libraries for all DLLs referred to by libserialport. For cfgmgr32.lib and setupapi.lib this would require the installation of the Platform SDK. But fortunately the Mingw variant of ld is able to link directly against DLLs instead of import libraries (see https://sourceware.org/binutils/docs-2.17/ld/WIN32.html). The line
LDLIBS += -lcfgmgr32 -lsetupapi
in the Makefile makes use of that feature. ld even finds the two DLLs in Windows\System32 without further hint.
In contrast to the Cygwin project the MinGW project isn't about bringing *IX features to Windows. Therefore it's not surprising that Mingw-w64 doesn't include support for mmap(). Fortunately this issue as already been solved - in fact several times. I chose the implementation in https://github.com/digitalinteraction/openmovement/tree/master/Software/AX3/omconvert as it seemed straightforward. If actually using the code should show issues I'd maybe try another variant.
Note: The mman.h "adapter" was added by me.
The libserialport is part of PulseView. Therefore there's no standalone binary distribution of libserialport for Windows. The official alternative is to build libserialport from the sources. However, the official way to do so (see https://sigrok.org/wiki/Windows#Native_build_using_MSYS2) requires a full MSYS2 installation. This makes sense as the official build implies 'autogen.sh' and 'configure' (see https://sigrok.org/wiki/Libserialport).
The search for a more lightweight approach requiring only a pure Mingw-w64 installation revealed https://github.com/scottmudge/libserialport-cmake. However, its build description says 'Make sure you have installed one of the Windows SDKs (I have tested 8 and 10) so that you have the dependencies required for windows (cfgmgr32.lib and SetupAPI.Lib).' 'And obviously you need CMake installed as well.' So that still wasn't exactly lightweight.
But fortunately it also says 'I have also included precompiled libraries for x64 versions of Windows if you'd like to use those. Just make sure to copy libserialport.h into your "include" directory.'
From: John Brooks <jbrooks@blueshiftinc.com>
Date: Thu, 25 Jan 2018 14:50:09 -0800
To: Oliver Schmidt <ol.sc@web.de>
Sure the MIT license is fine by me. I hereby agree that the xHD client &
server source code and executables should be open-sourced to the public on
github under the MIT license.
-JB
