[FacuM]

Summary

First pass of milestone M4 ("Packaging and updates", docs/design/00-integration-review.md §6).

C31: Dokany VC++ dependency (first-week check)

dumpbin /dependents on dokan2.dll from the pinned v2.3.1.1000 Dokan_x86.msi, Dokan_x64.msi and Dokan_ARM64.msi (each expanded with msiexec /a). Every architecture imports only KERNEL32, USER32, ADVAPI32 and SHELL32, with no VC++ runtime.

• D32 resolves to form (a): the offline EXEs embed the official per-arch MSIs, and the DokanSetup.exe bundle is not needed.
• The VC++ redistributable is not a prerequisite for GPO/Intune deployments.

Package and DLL SHA-256 values are recorded in docs/dev/m4-notes.md.

M4 row audit

docs/dev/m4-notes.md → "M4 row audit" goes through the M4 row requirement by requirement (done / partial / missing / blocked, with evidence).

Main open items:

• No x64 stub/payload and no universal multi-flavour EXE in any preset.
• No ARM64/ARM32 MSI (D31 requires ARM32).
• The setup EXE never passes TRANSFORMS (C43).
• Dokany chaining is not wired, and dokany.lock is missing.
• Restart Manager and C4's versioned shell-extension directory are missing.
• No sparse-MSIX build switch (D27).
• The release roots and keys are absent, so update verification and payload signatures fail closed.
• The service is M5.

Gap closed: webdav-tune (C28)

webdav-tune was a silent no-op, so per-machine installs kept WebClient's 50 MB file and 1 MB PROPFIND limits.

• --apply sets FileSizeLimitInBytes = 0xFFFFFFFF and FileAttributesLimitInBytes = 100000000. It first records the original values, once, in service\state\webdav-tune.ini; repair runs keep that first record.
• --revert restores the originals (deleting values that were absent before) and removes the record.
• BasicAuthLevel is never touched.
• Fail-closed: a value of another type or a damaged record makes the hook exit 1 without changing anything.

The MSI custom actions were already authored.

Tests

• 5 new cases in tests/apps/test_hooks.c run the real hook through sd-test-host-fake.exe. They are redirected to an HKCU key and a temporary ProgramData folder, so no machine state is touched.
• tools/ci-local.ps1 passes on x64-modern, x64-xp, x86-ia32, x86-sse2 and x64-analysis. dokany.mount is skipped under WOW64 on the x86 presets, as expected.
• Interop ran against the WSL sshd fixture of the main checkout (SD_SSH_WSL_FIXTURE_DIR); the notes explain why a worktree needs that.

Open decisions (not taken here)

1. ARM32 MSI: D31 says to ship one, but the MSI tools cannot run in an ARM tree. Should the ARM MSIs be built by a cross-tree msi target in this milestone, or deferred to M6 with ARM64?
2. Universal EXE: should the multi-flavour stub (x86-ia32/x86-sse2/x64-xp/x64-modern payloads in one EXE) be assembled in CMake or only in the release pipeline?

ARM64 and ARM32 MSIs (D31, commit 636fa87)

• ARM trees with SD_BUILD_MSI build their MSI. They use the sd-msigen, sd-msiembed and sd-test-msi tools from their nested x64 host-tools build.
• ARM32 package: CLI and host only (Core and Autostart), with no Dokany option. Its launch condition refuses Windows RT and Windows 11 24H2 or later (build 26100+). It adds one new installer string, localized in all six locales.
• ARM64 package: same contents as the x64 one, plus the x86 shell extension in the 32-bit view.
• Tests: msi.arm64.* and msi.arm32.* pass on the x64 host: tables, admin image with a PE machine check, and wixui. The ARM ctest presets now select ^msi[.].
• Gate: tools/ci-local.ps1 passes on x64-modern, x64-xp, x86-ia32, x86-sse2, x64-analysis, arm64 and arm32.