It'd be nicer to do this via
if (is_defined(HAVE_WHATEVER))
But MSVC won't work with the linux kernel macros for this. Ongoing
research.
Nevertheless, this makes most of the program always pass through the
compiler's type checker, only to have dead code removed later.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The WintunCreateAdapter()+CreateAdapter() and WintunDeleteAdapter()+
DeleteAdapter() communicate using Unicode anonymous pipes now. This
allows the WintunCreateAdapter() to exactly determine the adapter
CreateAdapter() just created by its GUID rather than its name - avoiding
the possible ambiguity caused by same-adapter-name ordinal suffixes.
This also allows exact retrieval of the result code and pending reboot
flag from the rundll32 child process.
Furthermore, CreateAdapter() and DeleteAdapter() are now available in
_DEBUG for all platforms to allow testing. It took a #pragma comment(
linker, "/EXPORT") trick to stop compiler from decorating function names
and exporting as _CreateAdapter@16() and _DeleteAdapter@16() in x86.
Signed-off-by: Simon Rozman <simon@rozman.si>
Go supports only callbacks that return "something" of a size up to
uintptr. It panics on void-returning callbacks.
Signed-off-by: Simon Rozman <simon@rozman.si>
The WoW64 client will provide stdio handles to read the log messages.
Furthermore, the rundll32 calls could return results using stdout.
Signed-off-by: Simon Rozman <simon@rozman.si>
I need this for debugging. In production environment, WoW64 clients will
already call rundll32 elevated to SYSTEM.
Signed-off-by: Simon Rozman <simon@rozman.si>
Some functions of SetupAPI only work when invoked from a native process.
Registry and filesystem reflection makes them fail on WoW64. For WoW64
processes, a minimum set of rundll32 functions are provided.
Signed-off-by: Simon Rozman <simon@rozman.si>
