Wos Woa Dashboard

Windows on Arm Ecosystem Dashboard lookup

Snapshot date: 2026-07-09 Freshness policy: the curated tables below reflect the Windows on Arm ecosystem as of the snapshot date. If more than 6 months have passed since that date, treat any package status as advisory only and re-verify against the live Arm Windows on Arm Software Dashboard plus the package manager (vcpkg search, npm view <pkg> cpu, pip download --platform win_arm64, crates.io platform list). Report the snapshot date and any drift in the Phase 8 report so downstream reviewers know which entries were re-checked live vs served from cache.

Reference: Arm Windows on Arm Software Dashboard and Arm AppReady program.

Every dependency the project imports MUST be classified into one of four dashboard states plus one of three runtime states. The wos-analyzer populates the mapping; the wos-porter Phase 8 report cites the results.

Dashboard states (per Arm's dashboard)

Runtime classification (Arm three-way split)

Curated known-status list

Cross-check every dependency against this list first; fall back to the live dashboard if the package isn't listed. Update entries when upstream state changes.

C / C++ ecosystem

Rust ecosystem

Node.js / npm

Python

.NET / managed

Kernel / driver code

Kernel-mode ARM64 porting is out of scope for wos-porter — flag every *.sys / *.inf targeting NTx86 or NTamd64 as Blocking + escalate to App Assure.

Lookup workflow

For each dependency wos-analyzer finds in a manifest (vcpkg.json, Cargo.toml, package.json, requirements.txt, *.csproj, binding.gyp, packages.config, etc.):

1. Look up the exact package name in the tables above.
2. If not found, probe manifest metadata:
   • vcpkg: vcpkg search <pkg> + check the port for supports = "!(uwp | arm)" (means unsupported on ARM) or supports = "arm64" (native).
   • Cargo: cargo tree -e no-dev and check crates.io for aarch64-pc-windows-msvc in the "Platform" list.
   • npm: npm view <pkg> os cpu — a cpu field missing arm64 means no prebuilt.
   • PyPI: pip download --platform win_arm64 --only-binary=:all: <pkg> — no download means no wheel.
3. Classify runtime state:
   • AA64 binary shipped → ARM64 native
   • Buildable from source with MSVC ARM64 → ARM64 native (mark as build-from-source)
   • Only x64 binary + no source → Emulated x64 (acceptable only for non-hot-path)
   • Kernel / HAL / hypervisor / Intel-only ISA → Blocking

Output format for wos-analyzer

Append this table to the analyzer's Dependencies section:

### Windows on Arm Dashboard Classification

| Dependency | Version | Manager | Dashboard status | Runtime class | Citation |
|---|---|---|---|---|---|
| openssl | 3.3.0 | vcpkg | native | ARM64 native | https://developer.arm.com/ecosystem-dashboard/windows |
| sharp | 0.32.6 | npm | building | ARM64 native (rebuild-from-source) | package.json |
| tensorflow | 2.15.0 | pip | unsupported | Blocking | https://www.tensorflow.org/install/pip#windows-native |
| my_kmdf_driver.sys | — | in-tree | — | **Blocking** (kernel) | escalate: App Assure |

Output format for the Phase 8 Arm AppReady Status section

- **Target profile**: ARM64-native
- **AppReady stages reached**: Assess ✓ | Build ✓ | Optimize ✓
- **WoA Ecosystem Dashboard status**: 12 native, 1 building (sharp 0.32.6 → rebuild), 0 unsupported, 0 unknown
- **Emulation vs native**: 13/13 dependencies loaded as ARM64 native; 0 emulated; 0 blocking
- **Blockers requiring Microsoft App Assure**: None

If any Blocking row exists, the Phase 8 gate G4b (add to G4 family) fails and the porter must record it in the Limitations & Known Issues section with the App Assure escape-hatch link.