[FEATURE] Windows Native Support

[seiggy]

Is your feature request related to a problem? Please describe.
Some developers may not be allowed to run WSL or Python on their development machines.

Describe the solution you'd like
A native Windows Binary distribution is necessary along with PowerShell support.

Describe alternatives you've considered
.NET port of codebase to support native AOT compilation + NuGet tool distro - heavy support lift.

[danielmeppiel]

Hey @seiggy — thanks for raising this. The use case is totally legit and I appreciate the context on enterprise policies that block Python/Node.js/WSL. I've done a full audit of the codebase to understand what Windows support would actually entail.

Current state

The Python source is largely cross-platform already — we already have win32 branching in our tool detection helper and platform detection that returns "windows". The core commands (compile, install, init, run) are mostly Python + git subprocess calls, all using pathlib.Path for file I/O.

What's not cross-platform:

Area	What's blocking	Effort
Binary distribution	CI matrix only has Linux + macOS runners. No windows-latest in build pipeline.	Low — PyInstaller already knows how to produce .exe
Install script	install.sh is bash-only	Medium — need install.ps1
Self-update (apm update)	Downloads and runs install.sh via /bin/sh	Medium — needs platform-aware update path
Runtime setup (apm runtime setup)	All setup scripts are bash (.sh), invoked via bash, uses chmod	High — need PowerShell equivalents or Python-native setup
Script runner	Uses shlex.split (Unix-oriented), shell=True	Medium — needs cmd.exe/PowerShell-aware execution path

Implementation direction

I'm thinking a phased approach makes sense:

Phase 1: Windows binary + core commands (the 80% case)

• Add windows-latest (x86_64) to the CI build matrix
• Create install.ps1 for Windows distribution
• Fix the apm update command to be platform-aware
• Test and fix any remaining path separator / subprocess issues in core commands
• Result: apm compile, apm install, apm init, apm run work on native Windows

This phase is where the most value is — developers get a native .exe binary that handles the core workflow (install AI primitives, compile prompts for their runtimes) without Python or WSL.

Phase 2: Runtime management on Windows

• Create PowerShell equivalents for setup-copilot.sh, setup-codex.sh, setup-llm.sh
• Make RuntimeManager platform-aware (detect OS, pick .ps1 vs .sh)
• Make ScriptRunner handle PowerShell/cmd execution
• Result: apm runtime setup works natively on Windows

Phase 3: Distribution channels

• Scoop package for community installs
• Potential Chocolatey / winget manifests
• NuGet tool package if there's demand from enterprise (wrapping the .exe)
• Result: enterprise-friendly distribution via private package registries

On the .NET port

I don't think a full .NET port is necessary given the above. PyInstaller produces a fully self-contained .exe with the Python runtime embedded — no Python installation required on the target machine. That directly solves the "no Python allowed" constraint. If NuGet distribution is what developers need, we can wrap the binary in a NuGet tool package.

What are your thoughts on this?

[seiggy]

@danielmeppiel - I like the idea of wrapping the binary in a NuGet tool package. That makes setup super easy with "dnx run" for .NET devs, and adding it to the global.json for repos to let devs know they should be using it. Chocolatey/Winget would also be easy for onboarding as well.

I'll take a crack at some of these powershell scripts to see if I can help out there. I've got a couple great test machines I can use that don't have python installed so I can easily validate everything works as expected.