Reported from a four-monitor pod: -tident filled the main screen green and did
nothing to the other three.
The first version opened each DirectDraw device with DDSCL_NORMAL and drew on
that device's primary surface. Under DDSCL_NORMAL a secondary device's primary
surface is not that monitor's framebuffer - it either fails to create or
resolves to the desktop primary - so every device painted the SAME screen, each
over the last. Green is acrFill[1], so device 1 painted last and devices 2 and 3
failed outright, which matches the report exactly.
Now does what the Windows Identify button does: one borderless topmost GDI
window per monitor, positioned from the rectangle that device's HMONITOR
reports, with a real message pump so the windows actually receive WM_PAINT.
Nothing takes exclusive mode and no display mode is changed, which was the point
of the original design and still holds.
Two things fall out of the rewrite:
* Devices resolving to the same rectangle are now grouped behind one window
labelled with both numbers ("1 & 2") instead of overpainting each other. That
was a parked item in CLAUDE.md - it happens when a driver presents one monitor
as two devices, which is common on a single-screen test PC.
* A device reporting no HMONITOR is the primary display driver alias and now
falls back to the primary monitor rectangle rather than being lost.
gos-displays.txt gains a painted size/position line per monitor, a
"shares a monitor with device N" line, and a summary count, so a failure to show
anything is visible in the log instead of silent.
Docs: this matters because RC2 told pod owners to run -tident and it did not
work. Added to the RC3 change list, corrected the now-obsolete known issue about
single-monitor overpainting, and rewrote checklist section 12 to lead with the
regression - all four monitors must be covered.
Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com>
Co-authored-by: GitHub Copilot <copilot@github.com>
c0daa2d920