Automate Windows apps (Desktop Mode)

Microbe Studio drives two kinds of target: Android emulator instances, and — in Desktop Mode — the Windows applications of this PC. Everything you already know carries over: the same flow editor, the same nodes, the same queue and scheduler. What changes is what a flow acts on, and one honest consequence of that: a desktop flow moves your mouse and keyboard, so this page is as much about staying in control as about building.

You do not need an emulator for Desktop Mode, and you do not need Desktop Mode for the emulator — they are two separate workspaces.

Turn it on

1. Desktop Mode is licensed as the Windows Mode capability of your License Package. If your package does not include it, the app tells you and stays in Emulator mode — check your package on the website.
2. In the app: Settings → Runtime Environment → Desktop.

Switching swaps the whole workspace, not a filter: the dashboard, the flow list, the queue and the scheduler now show desktop automation only. Your emulator flows, queues and schedules are untouched — switch back any time.

Your first desktop flow

The loop is the same one the Automation course teaches — act, then verify — so if you have built emulator flows, you already know how to build desktop ones.

1. Create a flow in the Desktop workspace. The toolbox is the familiar one, plus Open App and minus Zoom (a window has no pinch gesture).
2. Start with Open App pointing at the program you automate. If its window is already open, the node just finds it; if not, it launches the program and waits for the window — so the same flow works on a cold start and a warm one.
3. Act and verify exactly as on an emulator: Click, Find Image, Read Text. Capture templates and regions from the live preview of the real window.
4. Test Flow runs it end to end, with the same testing tools.
5. Run it for real from the Desktop Dashboard — or queue it, or schedule it. One desktop, one flow at a time: desktop runs are sequential, there is no instance fleet in this workspace.

What a node acts on

On an emulator, a node's target is obvious — the instance's screen. A desktop has many windows, so every acting or reading node carries its own answer, in the property panel's Execution Context group:

Target	Meaning
Active window (default)	Whatever window has focus at the moment the node runs
Specific window	One window, matched by description — works even when the user focuses something else
Desktop	The whole desktop, across every monitor
Monitor	One display (or "whichever is primary")
Region	A rectangle, anchored to a window, a monitor, or the desktop

The choice is per node, because real desktop work moves between applications: read a code from one window, type it into another, then check a notification on the whole screen.

A Specific window is described, never remembered by handle — a title fragment (case-insensitive), a process name, an executable, a window class, or a nickname you assign. Only the fields you fill in have to match. The Choose a Window picker lists what is running, and its Test Match button tells you how many windows your description currently matches — the number you want is exactly one, because at run time an ambiguous description is refused rather than guessed: two Chrome windows are not interchangeable, and silently driving the wrong one would produce an error no one can reproduce. See when it goes wrong below.

While it runs — staying in control

A desktop run uses the real mouse and keyboard, so the product never hides that it is happening:

• A small overlay shows the run's state. While the flow is driving, the overlay is fully click-through — it never steals a click or the foreground. It becomes interactive when the run is paused or has failed. You can set it to always show or never show in Settings → Windows; hiding it changes nothing about how flows run.
• The tray icon mirrors the same state, and a notification always fires when a run pauses — that one is not optional, because the real risk is a paused run nobody notices.
• Take back the machine by simply using it. Move the mouse or type, and the run pauses at the next node boundary (on by default, Settings → Windows). Every timeout and deadline in the flow freezes while paused — nothing "expires" because you answered an email mid-run.
• Resume with the overlay button, the tray menu, or the global hotkeys — Ctrl+Alt+S pauses, Ctrl+Alt+R resumes, from any window. Resuming gives you a 3-second countdown before input starts again, so the mouse is never snatched out of your hand.
• A scheduled run that pauses does not wait forever unless you want it to: after a configurable number of minutes it stops cleanly (set 0 to wait indefinitely).

Windows, size, and capture

Two mechanics worth knowing, because they explain what you will see:

• The window is put back the way the flow was drawn on it. Templates and click points are pixels against one window shape, so before acting, the run restores the target's state and size to what the flow was authored against, and re-measures. If the application refuses the size, the run is refused with both numbers — succeeding at the wrong coordinates would be worse. Moving a window to a monitor with a different display scale changes the pixel size of everything in it; that is reported, never silently "fixed".
• Reading and acting have different needs. For most windows, frames are read with a method that works even while the window is covered by others. Some applications (games and other hardware-accelerated windows) can only be read from the screen itself, which requires the window to be front-most — the window panel shows which method each window got, so "the preview went black when I covered it" is a fact you can predict, not a mystery. Input, in all cases, brings the target window to the foreground first.

Desktop Mode and the emulator, side by side

	Emulator workspace	Desktop workspace
Target	MuMu instances, many in parallel	This PC — one desktop, one flow at a time
Node toolbox	Standard set, with Zoom	Standard set, with Open App; no Zoom
Key Press	Android keys (BACK, HOME, …)	PC keys, and can hold Ctrl / Alt / Shift / Win for shortcuts
Input Text	The character set the emulator accepts	Full Unicode, independent of keyboard layout
Input goes through	ADB / the emulator's channel	The Windows input API — applications that read input hardware directly (some games) may not see it
Your mouse while it runs	Free — the run happens inside the emulator	In use by the run — pause any time by moving it

When a desktop run breaks

The debugging order is unchanged. The codes specific to this mode, in the order you tend to meet them:

Code	The situation
APP_LAUNCH_FAILED	Open App could not produce the window — check the recorded program path still exists
WINDOW_NOT_FOUND	Nothing matches the node's window description — the app is not running, or the description is too narrow
WINDOW_AMBIGUOUS	The description matches more than one window — narrow it; the run refuses to guess
TARGET_SURFACE_UNAVAILABLE	The window is minimized, or the monitor is gone
TARGET_CONTEXT_INVALID	The node's Execution Context is incomplete — open the node and finish its Target settings

All five are listed with the rest in Error codes.

Sharing and selling desktop flows

Desktop flows export, publish and sell exactly like emulator flows — see Flow Intellectual Property. The store reads the target out of the uploaded package itself and labels Windows-target flows, so a buyer always knows which mode a flow is for before paying.