SDV is using own CL.EXE which returns error code 2 when code analysis
is turned on. However, we need code analysis results for DVL.
While we could use a new "ReleaseSDV" configuration, we don't really
require limited code analysis in Release builds, as long as we address
all full code analysis warnings in Debug builds.
To make DVL happier, an intermediate Release build was injected with
code analysis turned on.
Signed-off-by: Simon Rozman <simon@rozman.si>
While the Wintun driver is typically released only at <major>.<minor>
milestones, the wintun.dll did see some intermediate releases.
To make MSI logic correctly decide to upgrade local wintun.dll file, the
version inscribed in wintun.dll file resources should increment in those
intermediate releases. MSI ignores file timestamps. One could use
REINSTALLMODE=emus Installer property to force copying wintun.dll when
its version doesn't change. But REINSTALLMODE applies to all files in
the MSI session and would be an additional requirement when authoring
MSI packages with wintun.dll.
Bumping only the final ZIP filename version is not sufficient.
Therefore, a <major>.<minor> or <major>.<minor>.<build> versioning is
introduced. Furthermore, we no longer distinguish between WintunVersion
and WintunVersionStr. All our releases used strictly numeric
<major>.<minor> notation, making WintunVersion and WintunVersionStr
always the same.
When the driver didn't change, just bump the version in wintun.proj and
run `msbuild wintun.proj /t:Zip` to rebuild the wintun.dll and make the
new ZIP file.
Signed-off-by: Simon Rozman <simon@rozman.si>
This adds the ARM driver to the list of Wintun drivers we compile for
future deployment. Since we're not in position to test it in the real
world, any feedback is greatly appreciated.
Suggested-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Simon Rozman <simon@rozman.si>
The ARM64 platform has no WHQL/Attestation driver available yet and the
Release build of the wintun.dll was explicitly designed to include WHQL/
Attn signed ARM64 driver only: There are no Windows on ARM64 before
Windows 10. This prevented alpha testing of the wintun.dll on ARM64.
Debug build includes EV signed ARM64 driver.
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>
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>
This commit is in many ways wrong, but when we're dealing with whql
imports, there's often a large gap in time, and it's useful to be able
to just restore everything exactly how it was prior and then build only
installer.dll and the msm.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
NdisMGetDeviceProperty() should always return non-NULL
FunctionalDeviceObject according to _Outptr_opt_. An explicit
FunctionalDeviceObject NULL check has been added to keep the SDV happy
and not calling our driver "defective".
Signed-off-by: Simon Rozman <simon@rozman.si>
No need for breaking every XML tag with attributes into lines - besides,
we're imposing 2-space indentation on .proj files making lines even
shorter and indentation combined with excessive line breaking harder to
follow visually.
Signed-off-by: Simon Rozman <simon@rozman.si>
This allows common version and other configuration in wintun.props.
- MSM packaging migrated to WiX MSBuild project and extended to support
digital signing
- Building supports single Platform|Configuration per run - again :(
- wintun.vcxproj cleanup
Signed-off-by: Simon Rozman <simon@rozman.si>
