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>
This should allow wintun.dll to simplify referencing same configuration
but different platform wintun.dll for WoW64 support.
Signed-off-by: Simon Rozman <simon@rozman.si>
1. Add driver to the store: SetupCopyOEMInfW()
2. Create the adapter using explicit path to .inf file: DI_ENUMSINGLEINF
3. Delete all Wintun drivers from the store.
This is a subject of further research:
- It appears those adapters survive a reboot. So, Windows must store the
driver somewhere on the disk and the driver removal is not completed.
If the driver removal is not completed until there are existing
adapters, this is excellent, as it will provide a self-cleanup.
- Test multiple adapters with different driver versions. Which driver
wins?
- Are other Wintun adapters interrupted when adding a new one?
- Test Windows 7 behaviour.
Signed-off-by: Simon Rozman <simon@rozman.si>
When debugger is attached, CreateDirectory() with SYSTEM-only SID fails
with "This security ID may not be assigned as the owner of this object.
(Code 0x0000051B)".
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>
While Doxygen correctly locates the function documentation when it is
written directly preceding the function body, Microsoft Visual Studio
IDE does not. The former requires the documentation to precede the
function declaration.
Signed-off-by: Simon Rozman <simon@rozman.si>
When an internal function logs an error and its cause, it bloats the log
when the caller logs the cause again.
Signed-off-by: Simon Rozman <simon@rozman.si>
Gather adapter management in adapter.h/.c (formerly devmgmt.h/.c) and
unify HwID tests.
Use "Namespace" namespace in all functions from namespace.h/.c.
Fix char strings in LOG_...
Signed-off-by: Simon Rozman <simon@rozman.si>
WINTUN_LOGGER_... => LOGGER_... => LOG_...
Those macros are internal, so they don/t need to start with WINTUN_...
Replacing the noun LOGGER_... with the verb LOG_... makes the code more
natural to read now.
Signed-off-by: Simon Rozman <simon@rozman.si>
With installer.dll the installer did the decision whether to install or
upgrade the driver according to installer.dll version and hash stored in
registry by MSM.
With wintun.dll we need to know, which version of Wintun driver we are
packing in the resources to decide about driver upgrade. The most
accurate source of the driver version is the DriverVer directive in
[Version] section of the driver's .inf file.
Signed-off-by: Simon Rozman <simon@rozman.si>
Quote from MSDN:
> You will need to call setlocale for _wcsicmp to work with Latin 1
> characters. The C locale is in effect by default, so, for example, ä
> will not compare equal to Ä.
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>
GetDevInfoData: Some functions returned ERROR_OBJECT_NOT_FOUND, others
ERROR_FILE_NOT_FOUND when the needle was not found in the haystack.
GetTcpipInterfaceRegPath: When IpConfig is an empty REG_MULTI_SZ, it is
actually ERROR_INVALID_DATA - like other unexpected registry values -
rather than a misleading ERROR_NETWORK_NOT_AVAILABLE.
Failure in TakeNameMutex result in ERROR_INVALID_HANDLE rather than the
ERROR_GEN_FAILURE with a misleading message: "A device attached to the
system is not functioning."
Signed-off-by: Simon Rozman <simon@rozman.si>
Rather than setting the "quiet" flag to each and every device in the
process of iterating, set it when actually creating/deleting it.
Signed-off-by: Simon Rozman <simon@rozman.si>
This makes the code more readable and works around the clang-format.exe
issues with _Return_type_success_ source annotation.
Signed-off-by: Simon Rozman <simon@rozman.si>
Mind that this also fixes the order of adapter detection checks. A fast
test to eliminate non-Wintun adapters from iteration to speed things up
rendered the method incapable of detecting a non-Wintun adapter with the
name we are looking for.
ERROR_OBJECT_NOT_FOUND was replaced with ERROR_FILE_NOT_FOUND.
Signed-off-by: Simon Rozman <simon@rozman.si>
Wix Toolset introduced an issue beginning with the v3.14.0.3827 release.
When linking merge module, the light.exe displays an internal error:
```
WixLink:
"C:\Program Files (x86)\WiX Toolset v3.14\bin\light.exe" -nologo -b o
utput_dir="..\amd64\Release" -spdb -sw1076 -sw1079 -out "..\dist\wintu
n-amd64-0.8.msm" "..\amd64\Release\installer-intermediate\installer.wi
xobj"
light.exe : error LGHT0204: ICEM10: The property 'ProductCode' is not al
lowed in a Merge Module [C:\Users\Simon\Projekti\wintun\installer\instal
ler.vcxproj]
C:\Users\Simon\AppData\Local\Temp\xdyw3dnt\wintun-amd64-0.8.msm : error
LGHT0204: ICE03: Table: Component Column: _IceM05Mark Missing specificat
ions in _Validation Table (or Old Database) [C:\Users\Simon\Projekti\win
tun\installer\installer.vcxproj]
C:\Users\Simon\AppData\Local\Temp\xdyw3dnt\wintun-amd64-0.8.msm : error
LGHT0204: ICE03: Table: File Column: _ICEM07CAB Missing specifications i
n _Validation Table (or Old Database) [C:\Users\Simon\Projekti\wintun\in
staller\installer.vcxproj]
light.exe : error LGHT0217: Error executing ICE action 'ICE103'. The mos
t common cause of this kind of ICE failure is an incorrectly registered
scripting engine. See http://wixtoolset.org/documentation/error217/ for
details and how to solve this problem. The following string format was n
ot expected by the external UI message logger: "There is a problem with
this Windows Installer package. A DLL required for this install to compl
ete could not be run. Contact your support personnel or package vendor.
". [C:\Users\Simon\Projekti\wintun\installer\installer.vcxproj]
The command ""C:\Program Files (x86)\WiX Toolset v3.14\bin\light.exe"
-nologo -b output_dir="..\amd64\Release" -spdb -sw1076 -sw1079 -out "
..\dist\wintun-amd64-0.8.msm" "..\amd64\Release\installer-intermediate
\installer.wixobj"" exited with code 217.
```
This error is not a direct consequence of anything being wrong in our
source code. Fortunately, the utility still produces identical MSM file
as previous WiX Toolset versions do. Unfortunately, it exits with code
217.
However, we need recent v3.14 for ARM64 support.
I know this is a huge issue for our build system, masking out any other
potential true error, but the light.exe exit code has been temporarily
ignored.
Signed-off-by: Simon Rozman <simon@rozman.si>
ARM64 support was introduced in Windows 10. There is no need to pack the
EV signed ARM64 driver for older Windows releases.
The only use-case we do want to pack an EV signed ARM64 driver (or test
signed) in the installer.dll is when we are doing the rundll32.exe
tests. Therefore, the Debug version still packs it.
If there is no driver available to pack, fail at compile time - rather
than build an installer.dll that would fail at runtime.
Signed-off-by: Simon Rozman <simon@rozman.si>
