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>
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>
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>
WireGuard is always doing so-called "minor" upgrade. This makes it
enough to run EvaluateWintun only once - somewhere after CostFinalize.
The component state we bind our driver install/remove logic to will be a
singleton: either be installed, left alone, or uninstalled. One single
action for install product session and RemoveExistingProducts session.
Other applications using Wintun might use the so-called "major" upgrade.
In this scenario the existing product is completely uninstalled first.
Including Wintun. The EvaluateWintun was called only once and it
determined that Wintun driver should be uninstalled. Since the MSI did
not execute EvaluateWintun again when installing the new product later,
the Wintun remained uninstalled.
In the case of major upgrades, the Wintun requires two separate action
logics: what to do with Wintun on uninstall of the old product, and what
to do with it when new product is installed.
Therefore, EvaluateWintun has been moved between InstallInitialize and
InstallFinalize to have MSI execute it in install and uninstall
sessions.
Reported-by: Dmitry Smirnov <dmitry.smirnov@netprotect.com>
Tested-by: Simon Rozman <simon@rozman.si>
Signed-off-by: Simon Rozman <simon@rozman.si>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
