CNA-BUG-239: Two stale comments in the Win32 backend: a nonexistent spike path and a wrong Windows version

CNA snapshot 009d40f5  ·  Known Issues › Current bugs  ·  source links pinned to 009d40f5

Win32DirectXIntegrationTests.cpp says real device and swapchain creation on the platform's handle is proved by spikes/win32-directx-spike/, a directory that has never existed (spikes/win32-spike covers window, message pump, DPI and QPC only, not a graphics device), and Win32Common.hpp's comment says it targets Windows 10 1703 while it defines _WIN32_WINNT and WINVER as 0x0603, which is Windows 8.1.

Identifier

CNA-BUG-239

Category

Bug

Subsystem

Documentation & release tooling

Status

Open

Verified against

CNA 009d40f5 (009d40f5dd085c4e674d3479675fac84b12b3e0a)

Severity

Low (a triage suggestion, not a project priority)

Evidence basis

Source-verified: read at TARGET, not executed

Tests touching this area

Yes: see Current tests

Affected contract

Source comments in modules/platform/tests/CNA/Platform/Win32DirectXIntegrationTests.cpp and modules/platform/src/Win32/Win32Common.hpp

Expected behaviour

A comment that names a spike directory should name one that exists, and a comment that states the targeted Windows version should match the _WIN32_WINNT value it sets.

Actual behaviour at TARGET

Win32DirectXIntegrationTests.cpp closes its header comment with 'Real device and swapchain creation on top of this handle is proved separately, by spikes/win32-directx-spike/'. That directory is not in the tree and was never committed: the string entered with the Win32 backend commit and appears nowhere else. spikes/ holds win32-spike (window, pump, DPI, QPC) and windows-unicode-path-spike, neither of which creates a graphics device, so the claimed separate proof is absent rather than merely misspelt. Win32Common.hpp comments 'Target Windows 10 1703 for the per-monitor-v2 DPI declarations' while defining _WIN32_WINNT and WINVER to 0x0603, which is Windows 8.1 (Windows 10 is 0x0A00). The DPI entry points are resolved at run time through Win32DpiSupport, so the header level has no functional effect; only the comment is wrong.

Source locations

• modules/platform/tests/CNA/Platform/Win32DirectXIntegrationTests.cpp — comment citing spikes/win32-directx-spike/
• modules/platform/src/Win32/Win32Common.hpp — comment 'Windows 10 1703' beside _WIN32_WINNT 0x0603

Evidence

Checked by reading both comments at 009d40f5 and listing spikes/ (no win32-directx-spike). 0x0603 is the documented _WIN32_WINNT_WINBLUE (Windows 8.1) value. Not executed.

Independent re-verification: Checked by reading both comments at 009d40f5 and listing spikes/ (no win32-directx-spike; the win32-spike probe does window, pump, DPI and QPC), and by a history search for the spike path (only the commit that added the Win32 backend contains it). 0x0603 is the documented _WIN32_WINNT_WINBLUE (Windows 8.1) value. Not executed. Correction to the earlier remedy: pointing the comment at spikes/win32-spike/ would be wrong; the test comment should drop the claim or a device-creation spike should be added.

Focused reproduction

No focused reproduction is known. Nothing has been invented here; the evidence above is what exists.

Current tests

Not applicable: comment-only defects.

Regression test

Point the test comment at spikes/win32-spike/, and correct the Win32Common.hpp comment to say Windows 8.1 (or raise the value to 0x0A00 if Windows 10 declarations are actually intended).

Blast radius

Maintainers following either comment. No runtime effect.

Workaround

No workaround is known.