Windows program automation starts with a three-backend launcher

Windows program automation is the practice of driving desktop applications (not browsers) through code instead of hands. Every tutorial jumps straight to clicks and keystrokes, but the first call in any real workflow is launching the target program, and Windows has three separate APIs for that. ShellExecuteW opens URIs and documents, ApplicationActivationManager.ActivateApplication is the only reliable way to start modern packaged apps without splash screens or AppContainer issues, and CreateProcessW is still correct for legacy Win32 .exe binaries. A Python script calling os.startfile or subprocess.Popen gets the legacy case right and everything else wrong. Terminator's open_application picks the right backend by inspecting the name you pass.

crates/terminator/src/platforms/windows/applications.rs. The entry point open_application is at line 459. If the name begins with ms-settings: it calls ShellExecuteW at line 471 and then opens the Settings window by name. Otherwise it tries get_app_info_from_startapps, and on a hit it calls launch_app, which wraps ApplicationActivationManager at lines 764 through 780. On a miss it falls through to launch_legacy_app at line 855, which calls CreateProcessW. Three branches, three Win32 APIs, one Rust function.

Get-StartApps is the PowerShell cmdlet that enumerates everything in the Start menu, including all UWP apps and their AppUserModelIDs. It is how Terminator resolves a name like notepad or Calculator into the AppID ApplicationActivationManager needs. Spawning PowerShell to run it is the expensive step. The source comment at line 541 says this saves ~566ms on every cached launch. CACHE_TTL is 30 seconds, which is long enough to cover a burst of launches in one workflow and short enough that new Store installs become visible quickly. The cache lives in a static Mutex<Option<StartAppsCache>> so every thread in the MCP agent shares it.

Because it is slow. A UIA walk over a cold desktop can touch thousands of HWNDs and issues cross-process COM calls on every one. The Win32 EnumWindows API runs in the same address space and just iterates HWNDs, checking GetWindowThreadProcessId for each against the target PID. Terminator's find_hwnd_by_pid_fast uses it (applications.rs lines 58 through 101). The inline comment at line 61 calls out the win: 10x to 100x faster than UI Automation tree traversal. That single change let the post-launch sleep at line 832 drop from 1000ms to 300ms while still catching slow-starting apps.

Terminator catches the error and retries via ShellExecuteExW with the special shell:AppsFolder\{AppID} path (lines 780 through 816). shell:AppsFolder is the Windows shell namespace that exposes every installed app as if it were a file. This handles the case where a Store app is installed but activation policy rejects the direct COM call, a common failure on enterprise Windows 11 builds. If that also fails to return a valid process handle, the code falls through to looking up the UI element by window name. Three fallbacks, so a single open_application call survives most real-world Windows configurations.

Yes. ApplicationActivationManager, Get-StartApps, ShellExecuteW, EnumWindows, and CreateProcessW are all present on Windows 10 1809 and later and every shipping version of Windows 11. The Windows UI Automation COM API the rest of Terminator uses has shipped since Windows 7. Terminator does not run on macOS or Linux for Windows program automation, since these APIs are Windows-only.

PyAutoGUI has no launch primitive at all. Its docs assume you use subprocess.Popen or os.startfile, which only cover legacy .exe cleanly. AutoHotkey v2 has Run with a FailIfNotFound parameter, which shells out via ShellExecute under the hood and works for .exe and document URIs but does not activate UWP apps by AppID. Power Automate Desktop has a Run application action, which is ShellExecute with extra wrapping, and a separate unofficial workflow for UWP that uses explorer.exe shell:AppsFolder. Terminator is the only framework in this list that tries ApplicationActivationManager first, which is the only API Microsoft actually recommends for packaged apps.

Both work. From Python: import terminator; terminator.Desktop().open_application('calc.exe'). From TypeScript: import { Desktop } from '@mediar-ai/terminator'; new Desktop().openApplication('calc.exe'). From Claude Code or Cursor: the open_application MCP tool (registered in crates/terminator-mcp-agent/src/server.rs) does the same. Every language binding resolves to the same Rust function in applications.rs, so the three-backend behaviour is identical.

Yes. open_application treats chrome, firefox, msedge, edge, brave, opera, vivaldi, and arc as known browser process names (the KNOWN_BROWSER_PROCESS_NAMES constant at applications.rs line 52). It still routes them through the same three backends, but downstream tools use that list to decide whether to attach the Chrome extension bridge for DOM-level automation versus treating the window as an opaque Win32 program. So a single workflow can launch Excel, Notepad, and Chrome and drive all three through the same selector language.