The Virtual Display Device (VDD) runs as part of the underlying virtual machine manager, and acts somewhat like a multiplexer for the video hardware. If a DOS a

The Virtual Display Device (VDD) runs as part of the underlying virtual machine manager, and acts somewhat like a multiplexer for the video hardware. If a DOS app is full screen, its commands are directly sent to the ‘real’ VGA adapter; otherwise, they’re emulated by the VDD. It's interesting to see others (re)discover this architecture, which IMHO was quite ahead of its time, since it predates modern hypervisors with hardware pass-through. The Windows 3.x GUI itself, including its preemptively-multitasked processes, effectively runs as an extended (protected-mode) DOS process inside a VM running DOS, and the hypervisor kernel, VMM32, is what multiplexes between it and other VMs running DOS processes. Thus one part of the display driver sits under GDI and interacts with the "hardware", while the other part in ring 0 virtualises the hardware and multiplexes it with the other VMs. This would fix it for DOSBox, but that fix would be tied to whichever video adapter it's emulating. I don't want that, I'm trying to make the generic VBE patch work better! Having written a Win9x VESA framebuffer driver for the Intel GMA950 as well, and added basic acceleration (blitter and fill commands), and encountering basically the same issue, I realised what may be the reason Win9x never came with a generic VESA driver: the VDD needs to know how to save and restore the GPU state, the details of which are obviously vendor-dependent. I did come up with some ideas on how that could be done generically, i.e. emulate/trace the VBIOS and see which ports/MMIOs it touches on each mode switch, but never got around to implementing it. While on DOSBox I get text mode with lots of corrupted characters, on the Eee PC I get a broken version of the GUI where some of the colours have disappeared. That looks like the palette registers didn't get saved and restored correctly. Also, the corruption at the top of the screen can be avoided by moving the high-res display plane up by 256K, so as to leave the first 256K of VRAM for the VGA plane and VGA emulation. Fortunately the Intel GMA has a bunch of publicly available documentation (although not for the 900 nor 950, and only for the 810/815 and 965+ but the majority of the registers and commands have not changed) you can refer to for the details.