Wondering, why WinDbg is refusing to load symbols for wintun.sys
recently...
By default, building puts .pdb files to the output folder. Next to the
final binaries: wintun.sys, wintun.dll, example.exe... Wait?! But the
wintun.pdb from wintun.dll overwrites the wintun.pdb from wintun.sys
then.
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>
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 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>
