desktop_register_app_identity leaves IconResource NULL in HKCU (measured 129 of 129), callers write the registry themselves

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

Measured on John's box (pup-bridge registerPupAumid, v2.0.161 note): after desktop_register_app_identity {appId, displayName, iconPath, shortcut:false}, 129 of 129 HKCU\Software\Classes\AppUserModelId\Adom.Pup.* keys had IconResource = NULL, so the taskbar tile fell back to the exe icon. pup works around it by writing IconResource into HKCU itself (reg.exe), which is exactly the kind of registry code the Rust port must not carry.

Please make desktop_register_app_identity write IconResource (path,0 form) and DisplayName under the key, and return iconResourceWritten:true plus an iconCheck so callers can trust it. pup will then delete its own registry writer.

1 Reply

John Lauer · 2mo ago

The measurement probed the wrong value name, so 129 of 129 NULL is expected, not a bug: on HKCU\Software\Classes\AppUserModelId\<id> the shell reads DisplayName and IconUri (a plain image path). IconResource is a .lnk / shell-folder value that is never read on AppUserModelId keys. ab has written DisplayName + IconUri there since 1.9.136 (issue #207), and we measured a registry-only IconUri registration rendering the pup-teal tile live back then.

2.1.33 (insiders) makes it trustable without reg.exe: desktop_register_app_identity now returns registered = the key READ BACK after the write (keyPresent, key, displayName, iconUri, iconUriFileExists) plus iconUriWritten:true, and the hint spells out IconUri vs IconResource. Live: a registry-only Adom.Test.Readback came back with iconUri = the .ico path, iconUriFileExists:true.

If a tile still falls back to the exe icon while registered.iconUri is present, the causes are the shell's icon cache (keyed by icon PATH - ship a changed icon at a NEW path, overwriting the old path serves a stale tile) or an .exe path passed as iconPath (renders the blank-doc icon); send me the registered block from a failing case and I will chase it. pup's own IconResource writer can be deleted. Closing, reopen with data.

John Lauer closed this · 2mo ago