[ArnauvGilotra]

What

The dictionary was parsed on every switch into the IME. This introduces canto-dictd.exe: a per-user, windowless, resident process that loads the dictionary once and answers candidate-resolution requests over a per-user named pipe. The IME becomes a thin client, so loading happens once per logon session (at startup or first use), not per activation.

Pieces

• CandidateEngine — the romanization → candidate segmentation/ordering logic, factored out of the text service verbatim so it runs where the dictionary lives (service, and the in-process fallback).
• DictProtocol — a small message-framed pipe protocol (SETDICT / RESOLVE / PING), header-only, shared by client and service. Per-user pipe name (derived from the user SID).
• DictService (canto-dictd.exe) — loads the user's selected dictionary at startup and serves lookups; single instance per user via a named mutex; windowless (WIN32 subsystem).
• DictClient — connects (spawning the service if absent), pushes the dictionary selection (SETDICT), resolves buffers. Falls back to an in-process load if the service is unreachable, so the IME never breaks.
• TextService no longer loads or holds the dictionary; BuildCandidates asks the client. The old background-load plumbing (WM_CANTO_DICT_READY / BeginLoadDictionary / OnDictionaryLoaded) is removed.
• Installer ships the service, starts it at each user's logon (HKLM Run, running as that user so it reads their settings), and stops it on uninstall.

Design notes / open questions

• One round-trip per keystroke: the whole candidate resolution runs server-side (not granular per-key lookups), so a keystroke is a single pipe request.
• Authoritative selection: the service preloads from its own read of HKCU (defaulting to Traditional), but the IME's SETDICT is authoritative and corrects it (e.g. a Simplified variant) on first activation.
• Fallback: if the service can't be reached, the DLL loads the dictionary in-process once and resolves locally — same result, just without the shared-load speedup.

CI-verified compiling only. The real latency win + the service lifecycle (logon autostart, on-demand spawn, reconnect, uninstall kill) need testing on the VM.

🤖 Generated with Claude Code