Subcommands gain one/two-letter aliases (dl, i, e, v, h) alongside
their full names. CLI-owned chrome - top-level usage, per-subcommand
usage lines, progress messages, and the license prompt - now goes
through internal/i18n, an env-driven message catalog (MSVC_GO_WINE_LANG,
falling back to the standard LC_ALL/LC_MESSAGES/LANG locale variables)
with English and Russian translations. Deeper error text from internal
packages stays in English.
Also refreshed the top-level usage text, which hadn't kept up with
--with-wdk/--list-workloads/--list-components/--print-deps-tree.
download --with-wdk fetches the WDK headers/libs/host-tools NuGet
packages (nuget.org has no vsman-manifest entry for this content) and
lays them out where the DriverKit.BuildTools PlatformToolset expects
them. msbuildEnv wires WDKContentRoot/WDKBuildFolder through
DisableRegistryUse the same way the SDK/toolset paths already are.
Two WDK-package fixups were needed for a real driver to actually
build under Wine: the bundled build-task assembly is versioned for an
older VisualStudioVersion than ours, and the package ships no x86
host-tools directory at all (only x64/arm64), which StampInf hardcodes
a path to.
Also force TZ=UTC for msbuild invocations: StampInf stamps DriverVer
using the local wall-clock date while Inf2Cat validates it against
UTC "now", so any timezone east of UTC sees a "postdated DriverVer"
failure for most of the day.
Verified against a real KMDF sample driver (microsoft/Windows-driver-
samples' echo_2): compiles, links, INF stamps and passes Inf2Cat's
signability check with SignMode=off.
- download --list-workloads / --list-components print every workload or
component id (with its manifest title) without downloading anything, for
discovering what to pass as a package id or --with-* toggle.
- download --print-deps-tree prints the dependency tree of whatever the
current flags would actually select, sharing the exact same
arch/--ignore/Optional/Recommended filtering ExpandSelection uses so the
output matches a real download; diamond dependencies are shown once and
referenced as "(see above)" afterwards to keep it finite.
- Fixed --manifest (offline/predownloaded manifest testing) never having
worked at all: it builds a "file:" URL but the shared http.Client had no
handler registered for that scheme.
- Added a CI workflow running gofmt/vet/build/test on every push and PR;
previously only the tag-triggered release workflow existed.
msbuild (and the toolrelay.exe-less fallback path for cl/link/etc.) inherited
os.Stdout/os.Stderr directly into the wine subprocess. Wine's wineserver and
its service processes (services.exe, winedevice.exe, explorer.exe, ...)
inherit those same descriptors and keep running well after the actual build
finishes, so a caller piping our output (`| tee`, `| tail`, CI log capture)
would never see EOF and hang indefinitely - even though the real build
completed in seconds.
Both paths now pipe stdout/stderr through our own copy goroutines, wait for
the tool's own process (not pipe EOF) to determine completion, and grant a
bounded 500ms grace period to drain whatever's already buffered before
moving on. Verified against a real hang (msbuild building freetype.vcxproj
piped through `tail`) and confirmed instant return after the fix, both on
success and on a build error.
msbuild <project>.vcxproj previously failed with MSB8020 ("build tools for
vNNN cannot be found") because MSBuild's own toolset/SDK resolution reads
a different set of environment variables than cl/link/lib do directly
(VCInstallDir_<N>, VCToolsInstallDir_<N>, VsInstallRoot,
WindowsSdkDir_10, WindowsTargetPlatformVersion, DisableRegistryUse, etc) -
none of which the generic INCLUDE/LIB/WINEPATH env covered.
Added msbuildEnv, populated for every MSBuild toolset generation actually
present under MSBuild/Microsoft/VC/v*, and wired into the msbuild wrapper.
Verified end-to-end: msbuild successfully builds ocornut/imgui's
example_win32_directx11.vcxproj (retargeted from its original v141
PlatformToolset to this install's v145) - compiles all 8 sources and
links against d3d11.lib/d3dcompiler.lib/dxgi.lib, producing a valid
PE32+ executable.
--dest (download) and the positional dir (install) were previously
required, forcing every user to pick and remember a location. Both now
default to a single hidden ~/.msvc-go-wine, matching the convention most
CLI tools use for their own data dir - still overridable for anyone who
wants a different location.
Was accidentally pinned to the locally installed toolchain's exact version
(1.26.5), which broke CI on runners with an older Go. Nothing in the code
needs anything newer than 1.23.
version is now settable via -ldflags -X for tagged builds instead of a
hardcoded "dev" string.
.github/workflows/release.yml cross-compiles linux/amd64 and linux/arm64
binaries on tag push (or manual dispatch), and publishes them to a GitHub
Release with checksums - the artifact packaging (Nivora's Staplerfile,
`go install`) is expected to consume from there.
A single-binary Go tool for cross compiling with the real MSVC toolchain
on Linux via Wine. Behaves as cl/link/lib/rc/midl/mt/dumpbin/msbuild/
nmake/ml/ml64/armasm/armasm64/cmd/findstr depending on the name it's
invoked as, plus download/install/env/version management subcommands.
- download: fetches the MSVC/WinSDK installer manifest, resolves package
selection and dependencies, downloads and verifies payloads, unpacks
VSIX/MSI packages, and applies a handful of compatibility patches so
VsDevCmd.bat and MSBuild's SDK detection work without a Windows
Registry (which doesn't exist under Wine).
- install: locates the installed toolchain/SDK versions, normalizes
header/library name casing, lays out per-architecture tool symlinks
with an env.json config each, and compiles a small native launcher
(toolrelay.exe) that lets mt.exe's CMake-compatibility exit code
survive Wine's own exit-code truncation.
- The wrapper runtime rewrites absolute unix paths in tool arguments into
Wine's z:\... form, runs the real .exe under wine, and rewrites the
tool's output back to plain unix paths.
Verified end-to-end against a real MSVC/WinSDK download: cl, link, mt and
the resulting hello.exe all work under Wine, including through the
toolrelay.exe relay path and with paths containing non-ASCII characters.
Offline unit tests cover the wrapper's path-rewrite/output-filter logic,
install-time header lowercasing, and download package-selection/
dependency-resolution.
Cheviiot