Expand description
Microsoft’s installer manifest, and the few packages in it an MSVC sysroot is made of.
Design: spec/cross-compile/13-distribution.md section 13.4, which is the Microsoft half of
crate::Wall.
§What this is for
The Windows SDK and the MSVC universal CRT are not ours to redistribute, so no release of this
compiler will ever pin an artifact for an MSVC target the way it pins one for mingw-w64. What
Microsoft does publish is an installer manifest that names every file the Visual Studio
installer would download, and a licence that lets a person who accepts it download those files.
That is the mechanism cargo-xwin uses and section 13.4 says we copy it. This module is the
reading half of that: given the two documents, which packages does a compiler need and which
files are those packages made of.
It fetches nothing and it writes nothing. Everything here is a function of text the caller was handed, which is the same rule the rest of this crate is held to.
§The chain, and the one link in it that is not a hash
There are three documents. The channel manifest, at a fixed aka.ms address, which names the
installer manifest. The installer manifest, which names every package and gives a sha256 for
every file in every one of them. And the files.
Every file is verified against the installer manifest, so the interesting question is what
verifies the installer manifest. The channel gives a sha256 for it, and as of this writing that
hash is wrong: aka.ms/vs/17/release/channel says the manifest for 17.14.37710.0 is 30443537
bytes long and hashes to 6e470016..., and the file served at the URL it names in the same
breath is 17954732 bytes and hashes to f0a50ea1..., from two different Microsoft regions on
two different days. Microsoft replaced the file and did not update the record.
So the record is not a pin, it is a note, and treating it as a pin means a command that never
works. Channel carries what the channel said and leaves the decision to the caller, which is
the honest arrangement: what actually protects the install is the per file hash a level down,
and what the channel adds is only a check that the CDN served the index the channel described.
A caller that reports both hashes gives a person auditing the download the one thing that
matters, which is exactly which bytes they got.
§What is chosen, and why it is so little
A C compiler needs headers and import libraries and nothing else. No linker, no assembler, no debugger, no redistributables, no spectre mitigated variants, no onecore flavour of the desktop libraries, and no tools of any kind, because the tool is this compiler. That comes to the CRT headers, two CRT library packages per architecture, and seven of the Windows SDK’s installers, which is ten files for one target out of a manifest with nineteen thousand packages in it. Five of the seven are the same whatever the architecture, so the three architectures we target come to seventeen files rather than thirty.
§Why the store package is one of the two
Because it is where Microsoft puts the import libraries for the DLL CRT, which is what a program
built the ordinary way links against. Measured by unpacking both packages of Visual C++
14.44.35207 for x86-64: the desktop package is 38 files, the static CRT and its debug
information, libcmt.lib and libcpmt.lib and libvcruntime.lib and the rest, and msvcrt.lib
is not among them. The store package is 96 files and has msvcrt.lib, vcruntime.lib,
oldnames.lib and the CRT’s own object fragments such as chkstk.obj in it. Both unpack into
the same lib/<chip> directory of a Visual Studio installation, so the two together are what
that directory is, and the store package’s store and uwp subdirectories are the part of it
that is actually about store apps and that an unpack leaves behind. xwin takes it for the same
reason and says so in the same words, which is a second opinion rather than the source of this
one.
§The cabinets are named by the installers rather than by the manifest
The Windows SDK half of the selection is MSIs, and an MSI holds no bytes: it is a small database
saying which cabinet each of its files is in and what that cabinet calls it, and the cabinets are
separate files in the same package, named by a hash. The newest kit publishes 149 of them and
they come to 484 MB, of which one target wants a fraction, so which cabinets to download is a
question only the installers can answer and this module does not guess at it. What it does is
carry them: Selection::cab takes the name an installer gives and hands back the file the
manifest publishes under it.
The newest version of each is taken rather than a pinned one. A pinned version would be a promise about a file on somebody else’s server, which section 13.8 already declines to make for the sysroots we do publish, and Microsoft retires old versions from the manifest.
Structs§
- Channel
- What the channel manifest says, which is the entry point and nothing else.
- Payload
- One file Microsoft publishes, as the manifest describes it.
- Selection
- Which files an MSVC sysroot for a set of architectures is made of.
- Wanted
- One file to download, and which package of Microsoft’s it came out of.