Changelog

First Windows release: the port of Anchr for macOS 1.0.0. Same problem, same product; what differs is the list of roles, because Windows' roles are not macOS's roles.

The product

• An ordered preference list per role, enforced when something moves your device. A device that isn't on your list is one Anchr has no opinion about (it will never route to it and never route away from it), so an unconfigured Anchr does nothing and ships switched on.
• Roles held independently. Listen on a Bluetooth headset while the microphone stays on your interface, so nothing ever opens a capture stream on the headset and it never collapses out of high-quality audio.
• "Never use a display's speakers" and "never use a Bluetooth headset as the microphone": rules about the kind of connection, so they keep working on hardware bought later.
• "Pick it again to keep it." Windows reports a person and a program changing the default identically, so Anchr resolves it with a second click that has to arrive at human speed. Offered in the window, in the tray menu, and in the notification: an interaction that only exists inside a banner does not exist for anyone who turned banners off.
• Stands down rather than looping against something that keeps grabbing a device, and says so.
• Settle window that coalesces device storms into one route. Windows needs this more than macOS does: a single Bluetooth headset arrives twice over, once as A2DP and once as hands-free.
• Import/export of the whole setup, an activity log, pause, re-apply now, and launch at sign-in.
• 13 languages. WCAG 2.1 AA, covered by a 372-test suite.

Windows-specific decisions

• Four roles, not macOS's three. Playback and Microphone (eConsole+eMultimedia, written together, because every Windows UI since Vista presents them as one "Default Device") plus "Calls: playback" and "Calls: microphone" (eCommunications, the "Default Communication Device"). The call roles are off by default.
• macOS's "System Sounds" is not shipped. Windows has no separate alert-sound endpoint; eConsole covers notification sounds but is bundled with games and voice commands and tied to eMultimedia everywhere in the OS. A fourth control that silently did nothing would be worse than not having it.
• Devices are identified by their property store, never by name. Form factor for display outputs, enumerator name for Bluetooth. The jack subtype is consulted only when the form factor has already admitted it does not know. On the development box, ordinary Speakers report an HDMI interface, and trusting the jack alone would have muted the only speakers the machine has.
• Setting a default endpoint goes through the undocumented IPolicyConfig COM interface, with the exact call verified on-box rather than taken from a blog post, and the result read back rather than inferred from the return code.
• IMMNotificationClient, not polling. Anchr is asleep except when hardware moves.
• Raw ctypes, not comtypes, matching the fleet, and required anyway since an undocumented interface has no type library.

Platform fixes made during the port

• A persistent WebView2 profile instead of pywebview's default private one. The default puts the profile in a temp folder and deletes it on exit, except WebView2 still holds files in it, so the delete fails and the folder is abandoned. The build box had accumulated 125 orphaned profiles totalling 450 MB before this was fixed.
• Quitting is bounded at roughly 0.2 seconds, watchdogged at 3 seconds, and does not wait on the window's own close handler. The updater launches the installer and quits so the installed files stop being locked; an installer that arrives to find the app still holding them installs nothing.
• Closing the window hides it; quitting is an explicit tray item. Anchr can only hold your devices while it is running, so treating the close button as "quit" would silently disarm the app.

Known in this beta

• SmartScreen may still warn on first download despite the signature; reputation builds per file. See the install notes.
• No screen-reader pass with Narrator or NVDA has been done by a human yet. The accessibility work is tested structurally and audited automatically, but assistive technology has not driven the app end to end. If you use one, that feedback is the most valuable thing you could send.