I’ve had my eye on Vista since the beta versions were released earlier this year. So far only the SimCoupe 1.0 release in July has included Vista-specific changes. These were:
Avoiding touching the primary display surface
SimCoupe uses a video overlay surface for the SAM display by default, which gives the best performance on old video cards. For this I must determine a colour-key value where overlay pixels should show through to the display, like green-screen special effects used on TV. This meant locking the primary surface to peek a pixel value, and that’s something Vista wasn’t happy with me doing.
In previous versions of Windows the primary display surface was what you saw on your screen, and where most objects were drawn directly. Vista’s Aero interface uses off-screen compositing for its fancy scaling and transparency effects. The visible display is managed by the compositing engine and is off-limits to direct manipulation. Any attempts to do so disables the Desktop Window Manager (DWM), returning the display to a compatibility mode. As part of this it also rather unhelpfully reports: “This program is not compatible with Windows”!
Video card overlays don’t really fit into the new composite world anyway. They can be scaled, but they can’t be rotated or skewed, and don’t support transparency. The DWM can’t make any use of them, so there’s little point in us trying to use them — problem solved!
SimCoupe no longer attempts to create a video overlay on Vista, and to avoid any confusion I also grey the setting in the options used to toggle it on and off.
Avoid querying the capabilities of the primary display surface
This is related to the first issue, but shouldn’t have been a problem at all. I found that simply querying the capabilities of the primary surface (using GetSurfaceDesc) was enough to disable the DWM.
This was confirmed to be a Windows bug in beta 1, scheduled to be fixed in beta 2. In the meantime I changed my code to work around it, using the required capabilities from the back surface instead.
Double-checking the main window is the correct size
The partial scanlines on the boot screen were showing a banding effect, which happens if the main window is resized to non-multiple of the natural display size. Further investigation showed the main window size (as set using AdjustWindowRect) was slightly too small.
This was yet another Windows bug, and not one I found documented anywhere! The size calculations didn’t seem to be including all the extra window decoration and the larger Vista borders were throwing it out. This just required a second size adjustment in SimCoupe if the first one was found to be wrong. This problem affected other programs that required an exact display size, which was mainly other emulators.
These changes were the bare minimum needed to run the program correctly under Vista. True Vista support will require additional changes, almost all related to the tightened security model. More about those in a future update.