Support for extended paths (cargo-wdk)

[svasista-ms]

Windows “extended” / “verbatim” paths (prefix ?\ for local/UNC, or ?\UNC\ for network) bypass legacy MAX_PATH (260) parsing and disable some normalization (e.g. no trimming of trailing dots/spaces, no interpretation of .. in the same way). Cargo itself accepts these paths. But, in PR #462 we removed custom canonicalize + strip logic and temporarily rejected extended paths to simplify the refactor. This can affect users when using:

• Very long working directories requiring ?\
• Scripts/tools that already pass verbatim paths
• UNC or long network share paths expressed in extended form

Currently this change impacts only the cargo wdk new command.

Goal: Restore seamless support for extended paths without re‑introducing complex custom normalization logic.

Risks / Considerations:

• WDK utilities (stampinf, signtool, inf2cat, makecert, etc.) haven’t all been validated with verbatim paths. Some of these tools might mishandle verbatim paths if they expect traditional forms—need a quick manual validation; if issues arise, we can selectively strip only for those tool invocations. Rejecting early avoided intermittent downstream failures.
• Logging: verbatim_path.display() (will show ?). Optionally add a helper to prettify logs for users.
• Security: Accepting verbatim paths should not broaden attack surface beyond existing path access.

Originally posted by @wmmc88 in #462 (comment)

[wmmc88]

@svasista-ms please provide more context in the issue body

[svasista-ms]

@wmmc88 , updated the issue description.

[krishnakumar4a4]

Is this issue #191 possibly related?

[wmmc88]

Is this issue #191 possibly related?

that issue is specifically about issues with the function that loads the makefile. that shouldn't be an issue with cargo-wdk now