This is fundamentally the wrong direction to go.<p>The clue is that MSWin running in a VM on Linux is faster than on hardware. The way forward is to boot Linux, or even something else, to manage hardware, memory, and filesystems, and cut down MSWin to run in a container on it. That way MSWin relies on the underlying OS to do things MSWin has proven to be just not very good at. MSWin runs programs written for it, reliably the same as non-hosted MSW, but is not subject to randomizing effects of manufacturers' drivers and MS's historically poor buffer and process management.<p>If you want MSWin to manage the screen, it can provide a way for an underlying OS program to work in a window it provides, and connect UI and clipboard events back to it. But MSWin is not really so great at display management, either, so it might be better for the underlying OS to manage that, too, as is done with VMs on X today.