win32
foundation
golang.org/x/sys/windows, no cgo
The shared Windows API surface the fleet's Windows code would otherwise re-declare per repository.
The Windows API from Go β the deliberate peer of go-macos/objc, so a cross-platform program talks to two libraries built the same way.
βwin32β is the name of the Windows API, not a bitness β there is no separate βWin64 APIβ. These target 64-bit Windows, amd64 and arm64.
Reference libraries, not re-implementations. winrt does not reimplement WinRT: RoInitialize and RoGetActivationFactory come from the reference projection, and this module adds only what is missing around it. Same rule as everywhere else in the fleet.
win32
foundationgolang.org/x/sys/windows, no cgo
The shared Windows API surface the fleet's Windows code would otherwise re-declare per repository.
winrt
extensionsaltosystems/winrt-go + the missing pieces
Activation and initialisation through the reference WinRT projection, plus only what that projection leaves out.
Deliberately thin: the value is in not having a second WinRT implementation to keep correct.
screencapture
captureDXGI Desktop Duplication + GDI BitBlt, through go-mswin/win32
Display and window capture as borrowed BGRA frames, allocation-free per frame. Two backends behind one API: DXGI Desktop Duplication where it is available, GDI BitBlt everywhere else and for occluded windows through PrintWindow(PW_RENDERFULLCONTENT).
Its proof record is checkable rather than asserted: a GDI capture and a duplication capture each matched QEMU's own independent screendump of the framebuffer in 0 of 480000 pixels, and CI re-runs the comparison so the record cannot drift from the files. What it has NOT proven β the GPU duplication path, a real 4K read-back, multi-monitor β is listed just as plainly.
The reason this org exists at all is symmetry: go-macos/objc gave the fleet's CGO-free macOS code one shared home instead of per-repo copies, and the Windows side deserved the same rather than a pile of hand-rolled syscalls.