Found via manual audit plus a staticcheck run:
- collectDependencyClosure iterated a package's dependencies map
directly, so which package "won" a same-key collision (and the
order things got downloaded/unpacked in) could vary between runs
of the exact same download command. Sort the dependency targets
first, matching what --print-deps-tree's tree-printer already did.
Verified two consecutive --print-deps-tree runs now produce
byte-identical output.
- HTTP retry loops (manifest fetch, payload download) retried
immediately with no backoff, which just hammers a server harder
during exactly the kind of transient failure retries exist for.
Added a capped exponential backoff (1s/2s/4s/8s/10s).
- --architecture/--host-arch accepted any string silently; a typo'd
value matched nothing during package selection and surfaced as a
confusing downstream failure far from the actual mistake. Now
rejected up front with a clear error.
- pumpLines' bufio.Scanner silently stops (dropping the rest of a
tool's output) if a single line ever exceeds its buffer - narrow but
real for pathological cases like heavily templated C++ diagnostics.
Now at least reports that truncation happened instead of losing
output with no trace.
- Removed select.go's unused off() helper (staticcheck U1000).
Re-verified end-to-end after these changes: a real KMDF driver build
and a plain cl/link build both still succeed.
Renamed the GitHub repo, Go module path, binary, and default install
directory from msvc-go-wine to vintner. Updated every user-facing
string (usage text, error prefixes, README, LICENSE, CI/release
workflow) and the embedded compatibility patches' own header text to
match; the VINTNER_LANG env var replaces VSMC_GO_WINE_LANG.
Also fixes a real bug found while re-verifying the rename end-to-end:
Microsoft.Cpp.WindowsSDK.props.patch had LF-only line endings in its
hunk body while the real Microsoft-shipped file it targets is CRLF,
so `git apply` silently failed on every real install and the SDK
detection fix it's meant to provide was never actually taking effect.
Restored matching CRLF endings in the hunk (checked against the other
five patches, which already had this right). Left the patch's
internal MsvcGoWine_ExtraSdkRoots MSBuild property name alone rather
than renaming it too - changing hunk content, even just an identifier,
breaks reverse-apply idempotency for anyone re-running download
against an already-patched tree, which the fix above depends on. Added
a .remove marker so an existing install's old-named props file gets
cleaned up on the next download.
Re-verified end-to-end after the rename: general MSBuild/cl/link
still work, and a real KMDF driver build (compile, link, INF stamping,
Inf2Cat signability check) still succeeds under the renamed binary.
README also gets an accuracy pass: WDK support and the download/env
CLI flags it lists were out of date (WDK was previously listed under
"Known gaps" despite being implemented and verified), the full tool
list was missing mc/cmd/findstr, and the new command aliases and
VINTNER_LANG option are now documented.
- 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.
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