Rust crate and source-file census for "Where Rust actually is in Windows 11" (per-file lists and the DWriteCore comparison are in the crates/ folder; the script is census.py)
=====================================================================================

What was measured
-----------------
Every Rust panic site embeds a core::panic::Location whose file string is the
source path.  We regex the raw bytes for `.rs` paths, repair the glue that
back-to-back Rust string literals create, and cross-check against a scan of the
Location structs themselves (pointer + length pairs), which give exact strings.
Paths are then classified as standard library (library/<crate>/src), crates
vendored inside the rustc toolchain (rust/deps or rustc/<hash>/vendor), registry
crates (<name>-<semver> under a cargo registry root), or first-party (the
directory before /src/).  "Canonical files" = distinct paths after stripping the
build-machine prefix, so the same file spelled two ways counts once.

Per-file results (registry crates / first-party crates / canonical .rs files)
----------------------------------------------------------------------------
win32kbase_rs.sys 10.0.26100.8972 : 1 registry crate (fallible_vec 0.1.0), 5 first-party crates
   (gdi_rust 8 files, rgncore 4, gdi_alloc 1, handle_manager 1, seh_unwind 1 = 15 files),
   std: core + alloc only (no_std kernel), 18 canonical files, 19 distinct paths, 21 raw ".rs".
   No rustc hash; toolchain path D:\os\tools\Rust\vpack\rust.tools (OS-repo vpack toolchain).
sudo.exe 1.0.1 (linked 2025-11-06) : 10 registry crates / 33 files (clap_builder 4.5.1 alone is
   17 files; clap_lex, anstream, anstyle, anstyle-parse, once_cell, which 6.0.0, windows 0.57.0,
   windows-core 0.57.0, windows-registry 0.1.0), 1 first-party crate (sudo, 5 files),
   std 4 crates / 50 files incl. library/panic_abort (built with panic=abort), 91 canonical files,
   105 distinct paths, 94 raw ".rs".  Toolchain rust.tools-x86_64-pc-windows-msvc.1.87.0-ms-20250722.10.
CloudRecoveryDownloadTool.dll 0.3.28.0 (linked 2026-05-22) : 59 registry crates / 228 files
   (tokio 1.52.3 = 44 files, h2 32, hyper 1.9.0 18, reqwest 0.12.4, serde_json, tracing-subscriber,
   native-tls + schannel ...), 8 first-party crates / 17 files (deploy-util 4, osget 4, deploy-ffi 3,
   cloud-recovery 2, async-util, deploy-logging, product-enumerator, syserr), std 79 files,
   328 canonical files, 349 distinct paths, 786 raw ".rs".  Toolchain 1.90.0-ms-20260302.10.
UdiApiClient.dll 0.4.45.0 (linked 2026-06-12) : 37 registry crates / 81 files (wrest 0.5.7,
   windows 0.62.2, windows-core 0.62.2, windows-strings 0.5.1, tracing-subscriber, serde_json,
   futures-*, parking_lot ...), 9 first-party crates / 30 files (udi-api 6, async-util 6, deploy-util 6,
   osget 5, deploy-ffi 2, deploy-logging 2, product-enumerator, syserr, wulib), std 72 files,
   187 canonical files, 206 distinct paths, 567 raw ".rs".  Toolchain 1.93.1-ms-20260416.7.
   Shares seven first-party crates with CloudRecoveryDownloadTool (same "deploy" code base).
NarratorMCAT.dll (NO version resource at all; linked 2026-05-20) : 26 registry crates / 125 files,
   0 first-party crates.  MathCAT itself is consumed as registry crates mathcat 0.7.0 (13 files,
   incl. braille.rs) + mathcat_c 0.7.0 from the Azure feed; the rest is regex-automata 0.4.14 (39),
   aho-corasick, regex-syntax, sxd-document/sxd-xpath, yaml-rust, zip 4.6.1, bzip2 ...  std 78 files,
   204 canonical files, 220 distinct paths, 312 raw ".rs".  Toolchain 1.95.0-ms-20260514.2 (stable-utc).
DWriteCore.dll 1.6.1.2406 (inbox CBS)         : 5 registry / 25 first-party (172 files) / 217 canonical
DWriteCore.dll 1.7.1.2411 (WSL settings)       : 5 registry / 25 first-party (170 files) / 215 canonical
DWriteCore.dll 2.0.1.2602 (Office WinAppSDK)   : 7 registry / 25 first-party (176 files) / 223 canonical
DWriteCore.dll 2.1.1.2605 (inbox CBS.2, Edge undocked_copilot, Office AI SDK) : 7 / 25 (176) / 223
DWrite.dll 10.0.26100.8972 (control)          : 0 .rs paths, 0 rustc hashes, 0 Location structs,
   0 UTF-16 hits; the only marker present is one __CxxFrameHandler3 import; _gnat = 0 everywhere.

DWriteCore trend
----------------
First-party crate rows are flat at 25 in every version (24 distinct names in 2.x once the build-script output row is
grouped with shaping_unicode_data), but the set turns over and grows in files:
  1.6.1 -> 1.7.1 : no first-party crate change; 2 first-party files dropped
                   (api_impl/text_layout_factory.rs, dwritecore_defs/font_face_reference.rs);
                   registry: com 0.6.0 dropped, windows-core 0.58.0 added, bumpalo 3.13->3.16,
                   smallvec 1.11->1.13.2, widestring 1.0.2->1.1.0.
  1.7.1 -> 2.0.1 : first-party bumpalo_pool and shaping_interop removed; shaping_cache (2 files)
                   and shaping_unicode_data/src/universal.rs added; layout 26->28 files (new.rs,
                   typography.rs), truetype 24->26 (newtrans.rs, sfnt/reader.rs), dwritecore_defs
                   +cache_context.rs; registry adds hashbrown 0.15.4, lru 0.16.0, windows-core 0.60.1.
  2.0.1 -> 2.1.1 : identical canonical source-file set (223 files) and identical rustc hash
                   (6a6eaca6...), but a different build (.text differs).
The three 2.1.1.2605 copies are the same build: identical .text/.data/.pdata/.rsrc/.reloc and the
same link timestamp (2026-05-08 18:22:06 UTC).  They differ in signing and in a small part of .rdata: the inbox copy has no
embedded Authenticode blob (catalog-signed), the Edge copy carries a 20128-byte signature and the
Office AI copy a 20832-byte one, plus a small .rdata difference.  No two copies are byte-identical.
Of the 172/170/176 first-party files, 10 in every version are build-script output
(shaping_unicode_data/out/fsm_data_generated*.rs), so hand-written first-party files are 162/160/166.
Largest first-party crates: shaping 36 files, otls 35, layout 26-28, truetype 24-26.

Toolchains and registries
-------------------------
Every binary that names a package uses Microsoft's internal rustc distribution (msrustup /
.ms_rustup_home packages): 1.87.0-ms (sudo), 1.88.0-ms (DWriteCore 2.x), 1.90.0-ms
(CloudRecovery), 1.93.1-ms (UdiApiClient), 1.95.0-ms (NarratorMCAT).  win32kbase_rs uses an OS-repo
vpack copy of rust.tools with no version string.  DWriteCore 1.6.1 and 1.7.1 carry only rustc
hashes (d34f430f..., c6bcfe6a...); both return 404 on github.com/rust-lang/rust, so they are not
upstream commits either.  Every registry crate in every file came from an Azure Artifacts feed
(pkgs.dev.azure.com-* or microsoft.pkgs.visualstudio.com-*); not one index.crates.io path exists.
Panic strategy: every user-mode binary except sudo has library/panic_unwind/src/seh.rs (unwinding);
sudo has library/panic_abort/src/lib.rs instead; the kernel driver has neither and ships its own
first-party seh_unwind crate.  Symbol-name markers (core::panicking, rust_begin_unwind,
__rust_start_panic, rust_eh_personality) are 0 in every file because release binaries are stripped;
they are not usable as indicators here.

Verification
------------
* grep -a -o -E '\.rs\b' | wc -l equals the script's raw count for win32kbase_rs (21),
  CloudRecoveryDownloadTool (786), UdiApiClient (567), NarratorMCAT (312) and DWrite (0).  It is
  lower for sudo (88 vs 94) and the DWriteCore copies (197/200/195 vs 207/205/207).  Every missing
  occurrence is ".rs" immediately followed by a byte in 0xC0-0xFF; this MSYS grep treats those
  Latin-1 letter bytes as word characters so \b fails, while Python's bytes \b is ASCII-only.
  grep -a -o -E '\.rs([^A-Za-z0-9_]|$)' reproduces the Python numbers exactly for all 12 files.
* Spot checks present: rust/api_impl/src/font_face.rs (+ dwrite and dwritecore_defs font_face.rs) in
  all six DWriteCore lists; rgncore/src/scan.rs in win32kbase_rs; udi-api/src/updateapi_exports.rs
  in UdiApiClient; mathcat-0.7.0/src/braille.rs in NarratorMCAT.
* DWrite.dll: 0 .rs paths, 0 rustc hashes, 0 Location structs.
* UTF-16LE .rs path matches: 0 in every file.
* Regex handling: (1) glued matches such as "string.rs/rustc/...iterator.rs" are split at every
  ".rs" followed by another path character; (2) glued prefixes such as "valueC:\__w\..." and
  "TryFromIntErrorrgncore\src\scan.rs" are repaired using the exact Location strings first, then
  drive-letter / /rustc/ / library/ / rust/<crate>/src/ anchors.  The anchor rules agreed with the
  oracle in every case where both had an answer; 0 pieces remain uncertain in any file.
  (3) build-script output keys drop the per-build metadata hash so generated files compare equal
  across versions.

Caveats
-------
* This counts source files that contain at least one surviving panic/assert/unwrap/bounds-check
  location.  Files and crates with no panic sites are invisible, so every count is a lower bound.
* The \b regex alone misses a path whose next adjacent literal starts with a word character
  (9 such paths in sudo, 16-23 per DWriteCore copy); the Location-struct scan recovers them and the
  "all distinct paths" / canonical columns include them.  The regex-only count is also in the TSV.
* "Distinct paths as spelled" exceeds "canonical files" where the same std file appears both as
  /rustc/<hash>/library/... and library/... (e.g. 225 vs 217 for DWriteCore 1.6.1).
* Link timestamps for win32kbase_rs, DWrite and DWriteCore 1.6.1 are reproducible-build hashes,
  not dates; the others decode to plausible dates and are reported as such.
* Standard-library file counts depend on which std code paths the binary exercises, not on how
  much Rust it contains; use first-party + registry counts for "how much Rust".